1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
[[meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation,
Inc."]]
[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled
[[GNU_Free_Documentation_License|/fdl]]."]]"""]]
Git repositories on Savannah, see <http://git.savannah.gnu.org/cgit/> (search
for *hurd*).
# Branches
Members of the [[Hurd_Savannah_group|savannah_group]] are allowed to create
branches without formal permission:
* named `BASE_BRANCH-SAVANNAH_LOGIN[-TOPIC]` for private general-purpose or
topic branches, respectively, or
* named `BASE_BRANCH-TOPIC` for public topic branches basing on
`BASE_BRANCH`.
`TOPIC` shall be a suitable tag describing the branch's main concern. These
tags can be applied recursively (`TOPIC-SUBTOPIC-SUBSUBTOPIC`).
*private* vs. *public* does, of course, in this scenario not mean visibility,
but instead authority: *private* branches are those that the user
`SAVANNAH_LOGIN` has authority over, whereas *public* branches are open for
every committer to install changes on. The private branches are those that you
would typically host on your own machine and publish through your own web
server, but we offer that you can instead do this from the centralized Savannah
repository, as a number of people don't have an always-accessible web server
running on their own machines.
Examples:
* GNU Mach
* `master` -- the mainline branch
* `master-oskit` -- port to OSKit; branched off of `master` at some point
* `master-gdb_stubs` -- add support for GDB stubs; branched off of
`master` at some point
* libpthread
* `master` -- the mainline branch
* `master-viengoos` -- port to Viengoos; branched off of `master` at some
point
* `master-viengoos-on-bare-metal` -- port to Viengoos running on bare
metal; branched off of `master-viengoos` at some point
## Merging
Merging between Git branches is trivial, at least as long as no conflicts
arise.
Due to this, you are encouraged to freely make use of separate branches for
different working topics, as this really faciliates concentrating on one
specific working topic.
You are encouraged to regularely merge from the respective mainline branches
(`BASE_BRANCH`; should be `master` in most cases) into your working branches,
and ensure that your modifications are still fine in the context of new
mainline changes.
Merging from working branches into the mainline branches will usually be done
by one of the project administrators, unless negotiated otherwise. For this to
happen, the copyright of your changes has to be assigned to the Free Software
Foundation; read about the
[[copyright_assignment_process|savannah_group#copyright_assignment]].
# Tags
Equivalent rules apply.
# Behavior
Try to not introduce spurious, unneeded changes, e.g., whitespace changes.
Adhere to the coding conventions that are already used. These are usually the
[GNU Coding Standards](http://www.gnu.org/prep/standards/html_node/) for stuff
written by ourselves, including new files, of course.
GNU Mach code is largely based on external code. Don't GNU-ify it, as this
would make merging external patches unnecessarily difficult.
## Commit messages
We no longer maintain parallel `ChangeLog` and commit messages. When needed,
the `ChangeLog` files can be created automatically from the commit messages.
Commit messages have this mandatory format:
One-line summary.
Blank line.
ChangeLog-like list of changes, but without leading tabs.
The header line of each former `ChangeLog` snippet (DATE NAME EMAIL) is no
longer to be included in the commit message, and instead the author and
committer of a change, together with the dates, will be maintained natively by
Git.
Example:
commit 3054666a46e0142cacef895c13edb4391435c722
Author: Some One <someone@example.com>
AuthorDate: Thu Jun 11 15:59:55 2005 +0000
Commit: Some One <someone@example.com>
CommitDate: Thu Jun 11 15:59:55 2005 +0000
Frobnicate the foo.
* frob.c (foo): Frob it.
* oldfoo.c [OLD] (oldfoo): Likewise.
[OLD_OLD_FOO] (oofoo): Permute every second word with itself, and
beginning with the tenth line, every third one also. Pure
nonsense.
Read about how to write [GNU-style `ChangeLog`
messages](http://www.gnu.org/prep/standards/html_node/Change-Logs.html).
Don't waste time writing exhaustive `ChangeLog`-like commit messages for, e.g.,
debugging stuff that will be removed again before merging your development
branch into the mainline. Sometimes the one-line summary might already
suffice. But please do write something.
## Behavior on *private* branches
Even though you are said to be the owner of branches tagged with your
`SAVANNAH_LOGIN`, it is generally nevertheless good to not do history-rewriting
stuff and the like (`git rebase` and friends), as others may in turn be basing
their work on your private branches.
We could establish a branch-tagging policy for branches that others should
expect their history possibly to be rewritten. This may be useful for branches
that are only meant for aggregating the changes of (several) development
branches, like an imaginary `master-proposed_for_general_testing` branch.
|
