Re: Document current policy for development with git.

[Stefano Lattarini]

At Thursday 29 July 2010, Ralf Wildenhues wrote:
> Hi Stefano, Eric,
> 
> thanks for the review!
Hello Ralf.

Sorry for the late answer, I missed your message somehow.

> > I like the wording.  However, I'd also like to see a simple
> > example, such as the one you provided me with in a previous mail
> > (which helped me a lot).  Do you think this would be overkill?
> 
> I agree that we shouldn't make the barrier for entry higher than
> necessary, but OTOH, if people are not firm with git then they need
> to post patches in the manner they are comfortable with; I'll
> rework them in that case.
> 
> Anyway, how about the additional patch below?
Good and useful IMO.

> > > +* There may be a number of longer-lived feature branches for
> > > new developments. +  They should be based off of a common
> > > ancestor of all active branches to +  which the feature should
> > > be merged later.  The next branch may serve as +  common
> > > ground for feature merging and testing, should they not be
> > > ready +  for master yet.
> > 
> > Shouldn't we mention the "next" branch before, together with
> > master and maint and branch-X.Y? That would make things clearer
> > IMHO.  For the rest, good and clear.
> 
> Yeah, maybe.
Hmm... I don't see it addressed in the additional patch below...

> > > +* master and release branches should not be rewound, i.e.,
> > > should always +  fast-forward, except maybe for privacy
> > > issues.
> > 
> > What about adding this too?
> > ``... privacy issues (e.g. if a developer has mistakenly pushed a
> > commit containing private or sensitive data)''
> 
> I don't care much either way, but I don't really see what
> additional information this would convey.
It's just slighty clearer and more explicit IMO.  Still, I don't care 
much either: this was just a minor nit.  So, please stick with the 
formulation you prefer.

Regards,
   Stefano