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 |