At Thursday 15 July 2010, Ralf Wildenhues wrote: > Hi Stefano, > > * Stefano Lattarini wrote on Thu, Jul 15, 2010 at 12:26:57PM CEST: > [ git-merge-changelog ] > > > However, there is a problem w.r.t. the Automake policy of keeping > > multiple ChangeLog entries with same author and date lumped > > togheter. In fact, git-merge-changelog seems to separate them > > when rebasing (see the attached script for an example). IMVHO > > the best thing to do here is to change the Automake ChangeLog > > policy, using e.g. > > > > 2000-01-01 Foo Bar <nob...@example.com> > > > > Add foo > > > > 2000-01-01 Foo Bar <nob...@example.com> > > > > Add bar > > > > instead of: > > 2000-01-01 Foo Bar <nob...@example.com> > > > > Add foo > > > > Add bar > > > > WDYT? > > Bruno prefers the former style, but maybe he accepts a patch to > optionally keep the style of the latter even upon rebasing. Well, I don't have a copyright assignement for Gnulib, and moreover the souce code of git-merge-changelog.c is beyond me ATM... of were you saying that you intend to write such a patch yourself? > I tend to just run another rebase -i to remove the extra > headers again, That's what I usually did too, but for longer patch series it is tedious, error-prone, and spoils the git-merge-changelog user experience. > or ignore the issue. If it's OK with you, this is what I'd like to do :-) > > And since we are at it, I have another question. If I have N (> > > 1) unrelated but simple patches to apply to maint, it's OK to > > apply all of them sequentially, and only then do the merges to > > master and branch-1.11? > > Yes, please, it's not only OK but I'd say strongly recommended. > The current mode of operation already produces a lot of merge > commits, and at least the merges from maint add mostly noise to > the history. Agreed.
> I'll try to update HACKING soon. Thanks, Stefano