Re: GNU-style ChangeLog merge driver for Git

[Bruno Haible]

Jim Meyering wrote:
> However, for those who would like a real ChangeLog file, I may simply
> add a Makefile rule like the one already in Makefile.am that will
> generate it upon demand.

This would be useful, yes. Or - since the ChangeLog is part of what should
be distributed and not erased by "make distclean" - it could be already
created by {autogen.sh,bootstrap}.

But wait... *generate* the ChangeLog? Is this possible at all?

- A ChangeLog should have the ChangeLog entries in the order in which they
  hit the HEAD branch. But when you are dealing with several branches
  and pulling from one branch to another, then can you guarantee the
  order of "git log" is the same as the desired order of entries in
  ChangeLog, i.e. the order of appearance of the patches in HEAD?
  Recall that git knows nothing about which branch is "closer" to HEAD.
  (I did a simple test with a merge and a rebase. This works fine. But
  the more complex cases?)

- When a patch was produced by 2 or 3 people jointly, we list all authors
  in the head of the ChangeLog entry. Can "git log" do this?

> If I have a patch series and want to reorder or combine change sets, I
> don't want to have to deal with *any* complications involving ChangeLog
> conflicts.  Also, when I amend a commit to affect an additional file,
> it's enough to change the commit log: I don't want to take the time to
> make an identical change to the ChangeLog.

This is understandable.

You change your way of working so that it works fine with the given versioning
system. I prefer to modify the versioning system so that it fits the way I
work.

Another point, about searchability: It would be highly useful to be able
to pick a particular ChangeLog entry and say "give me the entire patch
belonging to this entry". "git annotate ChangeLog" would be perfect for
this purpose. But on the web interface, "git annotate" is unsupported,
and on the command line, "git annotate ChangeLog" eats up more RAM and
swap space than my machine can offer. (This is maybe why they have
excluded "git annotate" from the web interface...)

You will certainly say: Of course, don't use "git annotate ChangeLog".
Use "git log". It's much faster!

Same point here: I don't want to adapt my way of working to git. I want
git to serve me.

Bruno