Gentoo Archives: gentoo-dev

From: Maciej Mrozowski <reavertm@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [git migration] Proposition for tags supported by git hooks
Date: Tue, 06 Apr 2010 07:29:53
Message-Id: 201004060928.50259.reavertm@gmail.com
In Reply to: [gentoo-dev] [git migration] The problem of ChangeLog generation by Nirbheek Chauhan
1 On Tuesday 06 of April 2010 04:13:02 Nirbheek Chauhan wrote:
2 > One of the few remaining problems to be solved for the migration to
3 > git for our gentoo-x86/ and gentoo/ trees (besides other
4 > projects/overlays) is the problem of how to handle ChangeLogs.
5
6 Great that you touched this topic.
7
8 > ========
9 > Problems:
10 > ========
11 > * Messages in ChangeLog are not always the same as the commit messages
12 > (~1% are different)
13 > * Some people place additional information in the commit message which
14 > is intended only for developer use
15 > - Most of the difference in ChangeLog/commit messages comes from this
16 > * Trivial changes are often not documented in ChangeLogs
17 > - This is upto the developer's personal preference
18 > - Some folks do this because of the extra time it takes
19 > + This use-case becomes irrelevant due to automatic generation of
20 > ChangeLog
21 >
22 > ========
23 > Solutions:
24 > ========
25 > * Do not re-generate the existing ChangeLog; rather make the ChangeLog
26 > generation script smart enough to only append
27 > - Solves the "messages not same" problem for existing commits
28
29 I don't think its' good idea, changelog should reflect state of remote
30 repository, not the state of local clone. Besides storing Changelog is simply
31 redundant and would increase repository size unnecessarily. It already
32 increases rsync size considerably.
33
34 > * Use a separator in the commit message like "== \n" to denote that
35 > everything after this is dev-only information and should be skipped
36 > from the user ChangeLog
37 > - Solves the problem for people who like to add extra dev-only info
38 > in the CVS commit message
39 > * Ignore commits with "[$tag][trivial]" in the tag[2] from being added
40 > to ChangeLog
41 > - Keeps the wishes of the developer and does not pollute ChangeLog
42 > with such info
43
44 Both would work fine, maybe tag syntax could be improved - certainly we want
45 it error prone and relatively simple to use - I've moved it to separate
46 subthread.
47
48 Maybe something like this: (modeled a bit after KDE tags allowed in svn
49 messages):
50 Each entry in its own line in commit message:
51
52 BUG: <bugnumber>
53 Marks the bug as RESO/FIXED, as comment adding full git commit message
54 with tags removed and just below gitweb URL corresponding to this
55 particular commit. For bugzilla, instead of full gitweb URL, maybe make
56 bugzilla aware of hashes in comments and expand gitweb links
57 automatically
58
59 CCBUG: <bugnumber>
60 Adds comment to the bugreport containing full git commit message with
61 tags removed and just below gitweb URL corresponding to this particular
62 commit. For bugzilla, instead of full gitweb URL, maybe make
63 bugzilla aware of hashes in comments and expand gitweb links
64 automatically
65
66 CCMAIL: <one-email-address>
67 Sends email to given address containing full git commit message with
68 tags removed and just below gitweb URL corresponding to this particular
69 commit
70
71 SILENT:
72 Marks entire commit message as "silent" by adding "(silent)" to the
73 subject of the mail or adding some mail header to allow filtering out
74 trivial commits. (like those containing typo fixes in comments and
75 such). Such commits could also be skipped by ChangeLog generator.
76
77 I specifically don't like [tag][sth] format, because I'd suggest to impose
78 some guidelines to git commit messages:
79 - put [$CATEGORY/$PN] in first line of commit message for git commits
80 related to packages
81 - same with [$profile] for profiles or [package.mask] for p.mask,
82 [eclass/$ECLASS] etc
83
84 to make history a bit more readable, see example:
85 http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary
86
87 Also some number (for instance up to 80) of characters from first line could
88 be used as email Subject in CCMAIL, so I think it's vital to have it organized
89 a bit.
90
91 --
92 regards
93 MM

Replies