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
