On Tuesday 06 of April 2010 04:13:02 Nirbheek Chauhan wrote:
> One of the few remaining problems to be solved for the migration to
> git for our gentoo-x86/ and gentoo/ trees (besides other
> projects/overlays) is the problem of how to handle ChangeLogs.
Great that you touched this topic.
> ========
> Problems:
> ========
> * Messages in ChangeLog are not always the same as the commit messages
> (~1% are different)
> * Some people place additional information in the commit message which
> is intended only for developer use
> - Most of the difference in ChangeLog/commit messages comes from this
> * Trivial changes are often not documented in ChangeLogs
> - This is upto the developer's personal preference
> - Some folks do this because of the extra time it takes
> + This use-case becomes irrelevant due to automatic generation of
> ChangeLog
>
> ========
> Solutions:
> ========
> * Do not re-generate the existing ChangeLog; rather make the ChangeLog
> generation script smart enough to only append
> - Solves the "messages not same" problem for existing commits
I don't think its' good idea, changelog should reflect state of remote
repository, not the state of local clone. Besides storing Changelog is simply
redundant and would increase repository size unnecessarily. It already
increases rsync size considerably.
> * Use a separator in the commit message like "== \n" to denote that
> everything after this is dev-only information and should be skipped
> from the user ChangeLog
> - Solves the problem for people who like to add extra dev-only info
> in the CVS commit message
> * Ignore commits with "[$tag][trivial]" in the tag[2] from being added
> to ChangeLog
> - Keeps the wishes of the developer and does not pollute ChangeLog
> with such info
Both would work fine, maybe tag syntax could be improved - certainly we want
it error prone and relatively simple to use - I've moved it to separate
subthread.
Maybe something like this: (modeled a bit after KDE tags allowed in svn
messages):
Each entry in its own line in commit message:
BUG: <bugnumber>
Marks the bug as RESO/FIXED, as comment adding full git commit message
with tags removed and just below gitweb URL corresponding to this
particular commit. For bugzilla, instead of full gitweb URL, maybe make
bugzilla aware of hashes in comments and expand gitweb links
automatically
CCBUG: <bugnumber>
Adds comment to the bugreport containing full git commit message with
tags removed and just below gitweb URL corresponding to this particular
commit. For bugzilla, instead of full gitweb URL, maybe make
bugzilla aware of hashes in comments and expand gitweb links
automatically
CCMAIL: <one-email-address>
Sends email to given address containing full git commit message with
tags removed and just below gitweb URL corresponding to this particular
commit
SILENT:
Marks entire commit message as "silent" by adding "(silent)" to the
subject of the mail or adding some mail header to allow filtering out
trivial commits. (like those containing typo fixes in comments and
such). Such commits could also be skipped by ChangeLog generator.
I specifically don't like [tag][sth] format, because I'd suggest to impose
some guidelines to git commit messages:
- put [$CATEGORY/$PN] in first line of commit message for git commits
related to packages
- same with [$profile] for profiles or [package.mask] for p.mask,
[eclass/$ECLASS] etc
to make history a bit more readable, see example:
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary
Also some number (for instance up to 80) of characters from first line could
be used as email Subject in CCMAIL, so I think it's vital to have it organized
a bit.
--
regards
MM
