Re: [QUESTION] Pushing patches.

[Stefano Lattarini]

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  <address@hidden>
> >     
> >     Add foo
> >     
> >   2000-01-01  Foo Bar  <address@hidden>
> >     
> >     Add bar
> > 
> > instead of:
> >   2000-01-01  Foo Bar  <address@hidden>
> >     
> >     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