[Top][All Lists]

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

Re: GNU-style ChangeLog merge driver for Git

From: Micah Cowan
Subject: Re: GNU-style ChangeLog merge driver for Git
Date: Mon, 11 Feb 2008 18:41:16 -0800
User-agent: Thunderbird (X11/20071022)

Hash: SHA1

Karl Berry wrote:
> I don't think it's exactly "recommended"; it's mentioned as an
> alternative, but in a rather ambiguous way (at least if we're talking
> about the same thing, in the Change Log Concepts node of standards.texi):
>        Another alternative is to record change log information with a
>     version control system such as RCS or CVS.  This can be converted
>     automatically to a `ChangeLog' file using `rcs2log'; ....

Yup, that's it. I'm not sure how it's ambiguous, though.

> Personally, as is somewhat implied here, I think it is highly desirable
> for there to be actual ChangeLog files in distributions, at least,
> independent of whether they are created from the vc logs.

Sure. I don't think anyone was saying otherwise.

> For background: I believe that rms relies on ChangeLog files in his
> distributions for legal information.  That's why the whole "(tiny
> change)" stuff exists, why the rules for who is given as the author are
> spelled out so precisely (Style of Change Logs), etc.  In the vc logs,
> the person who commits the change might not be the person who wrote the
> change.  What matters legally is who wrote it.

That's an important point, and one I'd thought about. I figured, though,
that where useful, someone could use some notation within the commit log
to indicate that a different user should be credited.

OTOH, a more difficult problem might be: how do you go about fixing
erroneous commit logs? In Subversion and CVS, this can be dealt with if
you have appropriate privileges; but in Mercurial at least (and probably
Git as well?), the commit log is a part of the changeset; you can't
change it without making it a wholly separate changeset. So if it's
already been published, it'd be impractical to correct; it'd require
some gnarly post-processing, then, to make the corrections.

Then again, there's a different sort of problem that's been irking me
somewhat with making ChangeLog entries (whether generated or manual),
ever since I started using DRCSses, and that is that the DAG nature of
change history in a DRCS doesn't map cleanly to a linear ChangeLog. That
is, you can no longer depend, for changes listed A, B, C, D, that all of
the changes A, B, and C were present at the time change D was made. This
can lead to false impressions about the context of a change entry, or of
the history of a particular section of code. This isn't causing me major
headaches, but then again, that's probably because I rely much more
heavily on the RCS's logs rather than ChangeLog files. I suspect the
time may be coming to discuss extensions to the canonical ChangeLog
format that would allow it to describe the source history in it's DAG form.

Though, I suppose simply complimenting the existing ChangeLog with an
alternate-format changelog taken straight from git or Mercurial,
including changeset parentage information, would be an acceptable way of
dealing with this. Mercurial's text-based "graphlog" extension might do
well for this
(see http://www.selenic.com/mercurial/wiki/index.cgi/GraphlogExtension
for sample output).

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

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