[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Document current policy for development with git.
From: |
Stefano Lattarini |
Subject: |
Re: Document current policy for development with git. |
Date: |
Sat, 31 Jul 2010 14:47:58 +0200 |
User-agent: |
KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) |
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