On Thursday 19 August 2010, Ralf Wildenhues wrote: > * Stefano Lattarini wrote on Thu, Aug 19, 2010 at 12:09:15AM CEST: > > HACKING: improve description of git "bugfix branches". > > HACKING: acknowledge Perl 4 as utterly obsolete. > > Nits below. > > > Subject: [PATCH 1/2] HACKING: improve description of git "bugfix > > branches". > > > > * HACKING (Working with git): Extend and make less terse the > > description of git "bugfix branches". > > grammar: ... and make the description of ... less terse. *blush* > or just: Extend. Yes, better. > > --- a/HACKING > > +++ b/HACKING > > @@ -139,9 +139,11 @@ > > > > # if all seems ok, then actually push: > > git push origin maint branch-1.11 master > > > > -* For bug fixes of long-standing bugs, it may be useful to commit them to > > - a new branch based off of the commit that introduced the bug, and merge > > - this bugfix branch into active branches that descend from the buggy > > commit. > > +* When fixing a bug (especially a long-standing one), it may be useful > > + to commit the fix to a new temporary branch based off the commit that > > + introduced the bug. Then this "bugfix branch" can be merged into all > > + the active branches descending from the buggy commit. This offers a > > + simple way to fix the bug consistently and effectively. > > Are you aware that merging fix-foo in maint, branch-1.11, and > master is equivalent to merging fix-foo in maint, then merging > maint in branch-1.11 and master (under the assumption that prior > to the fix, maint was an ancestor of branch-1.11 and master)? Yes. > If no, this paragraph should be rewritten, if yes, then how come you > didn't just merge maint into branch-1.11 and master? ;-) I was just describing the most genral scenario, that should work also in more unusual branching situations. Also, I said.... > This offers a simple way to fix the bug consistently and effectively. ... which doesn't mean it's the only way ;-) Moreover, an avarage git user with pushing right should know what you explained above, i.e. that... > merging fix-foo in maint, branch-1.11, and > master is equivalent to merging fix-foo in maint, then merging > maint in branch-1.11 and master (under the assumption that prior > to the fix, maint was an ancestor of branch-1.11 and master)? ... while the usefulness of the bug-fixing-through-branching policy you are using for automake might not be obvious (it wasn't for me until your explanation in a previous mail).
In light of these considerations, is my wording acceptable? > > Subject: [PATCH 2/2] HACKING: acknowledge Perl 4 as utterly > > obsolete. > > > > * HACKING (Editing automake.in and aclocal.in): Don't tell that > > Perl 5 is OK now: that's obvious! In fact, I'd be surprised to > > see anyone still using Perl 4... > > Let's keep our log entries concise, and no need to get excited in > them. configure already requires 5.6, so this would have been > sufficient, no? > > HACKING: Perl 4 is obsolete. > * HACKING (Editing automake.in and aclocal.in): Remove note about > Perl 5. OK, done. Regards, Stefano P.S. When you said ... > If no, this paragraph should be rewritten, if yes, then how come you > didn't just merge maint into branch-1.11 and master? ;-) ... were you asking why I didn't do that in my last push? Well, because I find an explicit merge of the bug-fixing branch in all the affected branches clearer: it's like saying "Hey, I'm doing this merge to fix a bug!", while this is unclear in a merge of e.g. maint.
