bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU-style ChangeLog merge driver for Git


From: Jim Meyering
Subject: Re: GNU-style ChangeLog merge driver for Git
Date: Mon, 11 Feb 2008 23:53:43 +0100

Bruno Haible <address@hidden> wrote:
> Jim Meyering wrote yesterday:
>> With the proliferation of "topic branches" in my work-flow, it is not
>> effective for me to version-control ChangeLog files (too many pointless
>> conflicts).  So, for projects that I control, I am transitioning away
>> from that.  ...
>> Instead, now, I compose ChangeLog entries solely in git log messages and
>> use the following script to generate a ChangeLog file at "make dist" time.
>
> So, people who now download your development version get the sources
> without any ChangeLog! If they are looking for the likely reason for the
> breakage on platform XY or of unit test foo/bar, they cannot look at and
> search through the version history, except if they have special tools
> (like "gitk") _and_ are familiar with them. You are throwing a proven
> and helpful GNU practice overboard. This is very bad.

That is a fallacious argument.

Would-be coreutils developers already have some requirements: they
must be able to read README-hacking and install all of the tools it
mentions.  Expecting them to know how to use "git log" is no different.
While "gitk" is useful, it's certainly not required to view the logs.

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.

> The real problem is, as you say and as everyone noticed, the pointless
> conflicts at the top of the ChangeLog file.

It's not just that.

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 also comes down to avoiding duplication: typically, I would put
almost exactly the same text in the commit log as I put in the ChangeLog
file, albeit with slightly different formatting.  Any time you do that,
where the nominally synchronized pieces can be changed independently,
they will sometimes get out of sync.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]