Re: [gentoo-dev] [git migration] Proposition for tags supported by git hooks

[Nirbheek Chauhan]

On Tue, Apr 6, 2010 at 12:58 PM, Maciej Mrozowski <reavertm@×××××.com> wrote:
>> ========
>> 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.
>

I think you've misunderstood this; ChangeLog appending would be done
entirely on the rsync server side. ChangeLog would be irrelevant for
the local clone. Also, the content of the old ChangeLog would anyway
already be in the history; so it doesn't take much space locally.

>> * 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.
>

If you see the link "[2]" which was
http://live.gnome.org/Git/CommitMessages you'll see that by that tag;
I meant the one inside the subject itself. Tags in the commit message
however are a good idea that I haven't thought about, and are used
extensively in other projects :)

> 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
>

++, we do something similar in the gnome overlay, and this change is
*very* much required because commit messages in git are quite
different from CVS.

cat/pkg-ver: I changed foo because of bar
eclass/gnome2: Fix stupid USE=doc behaviour

What you're proposing is also covered in the same link:
http://live.gnome.org/Git/CommitMessages

On an offtopic note; I would love to see git bz[1] work with our
bugzilla once the migration is done ;)

1. http://blog.fishsoup.net/2009/09/05/git-bz-push/
-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team