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
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
CONTRIBUTING.
Please read the following guidelines before contributing.
1. The basic unit of contribution is a "git commit". This will be merged into
master by one of the team members who will review it and sign-off/commit or
reject it. If the commit is in another branch, it will added to HEAD/master
using
git cherry-pick -s <tree-ish>
Or if the commit is submitted as a stand alone file produce by
git format-patch <tree-ish>
Then it will be committed by
git am -s 0001-foo-bar.patch
Or if the commit is submitted as a github merge request, then the github web
interface can be used.
2. Work in a branch immediately off of master, do not work directly in master,
and do not be afraid of creating a local branch for every experimental thing you
want to try:
git checkout master # make sure your on master
git branch idea1 # I've got an idea, let me work on it
git checkout idea1
<hack ... hack ... hack>
git commit -m "step1" # I like what I've done so far, but I'm not finished
<hack ... hack ... hack>
git commit -m "step2"
<hack ... hack ... hack>
git commit -m "step3"
<hack ... hack ... hack>
git revert <tree-ish for step2> # Wow step 2 was dumb
<hack ... hack ... hack>
git commit -m "step4" # Its good now, but those
# commits are messy
git rebase -i <tree-ish step1>^ # start a rebase on the parent of step1
(drop into editor and squash commits) # note the ^ at the end!
(exit editor and fix commit message)
Alternatively, you can cherry-pick those commits into another prestine branch:
... its good to go! ....
git checkout master
git branch idea1-clean
git checkout idea1-clean
git cherry-pick <sha1-of-good-commit1>
git cherry-pick <sha1-of-good-commit2>
(pick them in any order that stacks)
(you can skip commits, but do them in the correct order to avoid conflits)
git rebase -i <tree-ish of sha1-of-good-commit1>^ # squash many commits into one
# note the ^ at the end!
Once you are done with a local branch you can delete it using
git branch -D idea1
You can delete a remote branch by doing
git push origin :idea1
3. Your commit message should conform to the following standard:
file/changed: Concice and complete statement of the purpose
This is the body of the commit message. The line above is the
summary. The summary should be no more than 72 chars long. The
body can be more freely formatted, but make it look nice. Make
sure to reference any bug reports and other contributors. Make
sure the correct authorship appears. Reference any early commits
by their full shaw:
b52c6402b5b42620571c36c74a12dcb45ec1e0d6
which you can put on its own line and indent.
X-Gentoo-Bug: 400837
X-Gentoo-Bug-URL: https://bugs.gentoo.org/400837
Reported-by: Snoopy Coderdog <charlie@brown.org>
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
If you commit using
git commit -s
your sign-off will be automatically added. If the authorship is wrong
fix it by
git commit -s --author="Richard Feynmann <quantum@electrodynamics.edu>"
If the message doesn't look right after you commit locally, you can fix it by
doing
git commit --amend.
Then push it to your public repo.
4.a Open an issue at (using GitHub)
https://github.com/gentoo/eudev/issues?state=open
And request a pull of your clean commit. A team member will review it,
discuss it and commit it to master or reject it.
4.b Send to mailing list (using git format-patch)
Make sure you are subscribe on the mailing list. If you do not, send an email to
eudev+subscribe@lists.gentoo.org
and follow instructions.
When sending patches to mailing list, use
git send-email --to eudev@lists.gentoo.org 0001-foo-bar.patch
5. eudev is a peer-reviewed project. So even team members must ask another
team member to sign-off and commit your work. The only exception are trivial
commits
6. HEAD/master must always build and must always be considered stable.
7. Releases should be tagged and signed using
git tag -s -u <gpg name> -m "Release X"
where X is the full release number. Make sure that before you release,
you change the value in AC_INIT of configure.ac to match the release
number.
8. Tarball releases should be made from HEAD/master at signed tagged points
by doing
autogen.sh
./configure
make
make dist
9. TODO: coding style for C, python, perl and autotool stuff.
|
GitWeb