1 |
On wto, 2017-07-25 at 22:28 +1000, Michael Palimaka wrote: |
2 |
> On 07/25/2017 06:05 PM, Michał Górny wrote: |
3 |
> > Hi, everyone. |
4 |
> > |
5 |
> > There have been multiple attempts at grasping this but none so far |
6 |
> > resulted in something official and indisputable. At the same time, we |
7 |
> > end having to point our users at semi-official guides which change |
8 |
> > in unpredictable ways. |
9 |
> > |
10 |
> > Here's the current draft: |
11 |
> > https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git |
12 |
> |
13 |
> This looks really nice, thanks for working on it. |
14 |
> |
15 |
> > * When doing a minor change to a large number of packages, it is |
16 |
> > reasonable to do so in a single commit. However, when doing a major |
17 |
> > change (e.g. a version bump), it is better to split commits on package |
18 |
> > boundaries. |
19 |
> |
20 |
> In some cases we do prefer to make major changes on a set of related |
21 |
> package all in one commit. For example, we always bump the 240+ KDE |
22 |
> Applications collection together because that's how it's released. |
23 |
|
24 |
It's merely a recommendation. I don't want to cover every single use |
25 |
case because that would be insane. I'm already worried I've covered too |
26 |
many cases for people to read it all. |
27 |
|
28 |
> > ===Commit messages=== |
29 |
> > A standard git commit message consists of three parts, in order: a |
30 |
> > summary line, an optional body and an optional set of tags. The parts |
31 |
> > are separated by a single empty line. |
32 |
> > |
33 |
> > The summary line is included in the short logs (<kbd>git log -- |
34 |
> > oneline</kbd>, gitweb, GitHub, mail subject) and therefore should |
35 |
> > provide a short yet accurate description of the change. The summary line |
36 |
> > starts with a logical unit name, followed by a colon, a space and a |
37 |
> > short description of the most important changes. If a bug is associated |
38 |
> > with a change, then it should be included in the summary line as |
39 |
> > <kbd>#nnnnnn</kbd> or likewise. The summary line must not exceed 69 |
40 |
> > characters, and must not be wrapped. |
41 |
> |
42 |
> Does a bug # really need to always be in the summary line? It can eat |
43 |
> valuable characters and tags which are pretty popular are equally valid IMO. |
44 |
|
45 |
Tags don't appear on 'git log --oneline' or cgit/gitweb shortlog. If you |
46 |
are groking through multiple bugs, it is more convenient if you can find |
47 |
the bug no straight away. |
48 |
|
49 |
> > ** <kbd>Bug: <nowiki>https://bugs.gentoo.org/NNNNNN</nowiki></kbd>;; — to |
50 |
> > reference a bug, |
51 |
> > ** <kbd>Closes: <nowiki>https://github.com/gentoo/gentoo/pull/NNNN</nowi |
52 |
> > ki></kbd>; — to automatically close a GitHub pull request, |
53 |
> > ** <kbd>Fixes: <nowiki>https://bugs.gentoo.org/NNNNNN</nowiki></kbd>;; — |
54 |
> > to indicate a fixed bug, |
55 |
> |
56 |
> grepping the git log shows that 'Gentoo-bug' is much more common than |
57 |
> plain 'Bug'. 'Fixes' is hardly used at all, and I think it's a bit |
58 |
> confusing to use this for bugs as well as commits. |
59 |
|
60 |
'Fixes' is the original tag used by other projects. 'Bug' is shorter |
61 |
than 'Gentoo-bug' and avoids repeating the obvious. Much like we do not |
62 |
have 'Gentoo-signed-off-by', 'Gentoo-thanks-to' and so on, having |
63 |
'Gentoo-bug' is equally silly. |
64 |
|
65 |
Furthermore, full URLs should be used with tags. If you are already |
66 |
using tags (i.e. long form), don't do it half-way and put useless digits |
67 |
there. Put URL that will be interpreted by practically all visual git |
68 |
tools written ever. |
69 |
|
70 |
> > a few branches on the repository, and did not maintain them. The Infra |
71 |
> > had to query the developers about the state of the branches and clean |
72 |
> > them up. |
73 |
> |
74 |
> Should 'The Infra' be 'The Infra team' or just 'Infra'? |
75 |
|
76 |
Yes, thanks. |
77 |
|
78 |
> |
79 |
> > Gentoo developers are still frequently using <kbd>Gentoo-Bug</kbd> tag, |
80 |
> > sometimes followed by <kbd>Gentoo-Bug-URL</kbd>. Using both |
81 |
> > simultaneously is meaningless (they are redundant), and using the former |
82 |
> > has no advantages over using the classic <kbd>#nnnnnn</kbd> form in the |
83 |
> > summary or the body. |
84 |
> |
85 |
> I agree that using both is redundant, but I don't agree with |
86 |
> discouraging or banning the use of 'Gentoo-bug'. If someone prefers to |
87 |
> use it so it sits nicely with the other tags why stop them? |
88 |
|
89 |
I'm not stopping anyone. This is merely a suggestion. Encouraging two |
90 |
different tags for the same thing would be confusing to users. |
91 |
|
92 |
-- |
93 |
Best regards, |
94 |
Michał Górny |