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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
|
[[!meta copyright="Copyright © 2011 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]]."]]"""]]
[[!toc]]
# Integrating Development Braches/External Sources
[[!taglink open_issue_documentation]]
IRC, freenode, #hurd, 2011-10-11:
<tschwinge> braunr: About integrating salloc (I'll just use this name).
<tschwinge> braunr: Ideally, as this is an external import, there should be
an empty Git branch where the initial-import code (right out of your
tree, for example) is added.
<tschwinge> braunr: Then this is merged into a GNU Mach salloc branch and
moved into the destination directory.
<tschwinge> Then, any bug fix patches that do not concern salloc itself,
should stay separately.
<tschwinge> Also, any improvements that are not specific to salloc itself.
<tschwinge> All other salloc development commits (try this; no this; fix
other thing; etc.) can be combined into one commit on the salloc branch.
<tschwinge> Does that make sense?
<tschwinge> braunr: The idea of the separate external/braunr-salloc-import
branch is that any external updates are applied to this branch (where
they'll apply) cleanly, and then it is merged into GNU Mach salloc (or
later master, once salloc is merged) again.
<antrik> tschwinge: if you really want to use a branch for the external
code import, better actually import it with its history, not just as a
snapshot
<antrik> (disclaimer: haven't actually tried how well this works in
practice...)
<tschwinge> antrik: Yes, generally this is even better, but:
<tschwinge> antrik: But typically the external code we want to import is
just a subset of its external repository. And I don't think we want to
have all of the external development history.
<antrik> that's the only sane way to do proper followup merges...
<antrik> admittedly it makes git log a bit confusing...
<tschwinge> antrik: Why is it the only sane way?
<braunr> tschwinge: "an empty Git branch", out of the gnumach git
repository ?
<braunr> tschwinge: then imported "into a GNU Mach salloc branch" ?
<antrik> tschwinge: otherwise you don't have merge history. you get no idea
why anything changed in the external code; and it's hard to merge any
changes happening in the local repository vs. the imports
<tschwinge> antrik: Of course, importing all the history may make sense at
times, but if we use the [Linux]/include/gcc-atomic.h header, we're
surely not going to import all the Linux kernel history for that.
Instead we would update our import branch with every upstream Linux
release, for example.
<tschwinge> braunr: You want me to clarify these points?
<braunr> tschwinge: yes please
<tschwinge> braunr: Start with an empty Git repository: mkdir import && cd
import/ && git init
<tschwinge> braunr: Add the files to-be-imported in there, adn commit that
as ``import ... version/Git commit from ...''.
<pinotree> tschwinge: maybe
http://book.git-scm.com/5_creating_new_empty_branches.html ?
<tschwinge> pinotree: Oh nice.
<tschwinge> pinotree: Thanks.
<pinotree> np
<tschwinge> Yes, can also do that, or a new Git repository as I said.
<tschwinge> braunr: Prefereably add the files in a salloc directory right
away to avoid any merge conflicts later on.
<tschwinge> braunr: Then, in GNU Mach, branch off of master: git checkout
-b salloc origin/master
<tschwinge> This will be the salloc integration working branch.
<tschwinge> braunr: Actually not ``in a salloc directory'', but with the
name the thing has in your upstream repository.
<tschwinge> Then, make the external import branch known here: git fetch
../import master:external/import-braunr-allocator
<tschwinge> Then you can merge the external branch into the salloc branch:
git merge external/import-braunr-allocator
<braunr> got most of it, except for the "salloc directory"
<tschwinge> Then, move everything in place, and either commit --amend it to
the merge, or a separate commit.
<braunr> ah, you really suggest a separate directory not to have any
conflict
<braunr> then a move
<tschwinge> Right.
<braunr> but there maybe conflict afterwards
<tschwinge> I take it that the alloc files live in [x15]/kern/allocator, so
you'd put them into kern/allocator in the new repository, and then (after
merging that branch) move them to kern/salloc (or similar).
<braunr> i'm not sure i get the point
<braunr> no they won't
<braunr> it will live in kern/salloc.c, and the additional required files
like list.h may be put there too
<tschwinge> Aha, OK.
<braunr> but these are clearly separate files, so it should give the same
results, right ?
<tschwinge> Well, you could in the import branch put them all into x15/,
then merge, then move the files to kern/salloc.c, misc/list.h, etc.
<braunr> hm let's call it salloc/ :)
<braunr> but ok
<tschwinge> It's just that the import branch should have the same structure
than upstream has.
<tschwinge> To faciliate further imports later on.
<braunr> well, that's why i don't see the point of the move
<tschwinge> And after the merge it should have the file system structure as
used by GNU Mach.
<braunr> and there will be no upstream; once it's in gnu mach, it has its
own life
<tschwinge> Ah, OK.
<tschwinge> Well, then it won't matter too much.
<braunr> wouldn't it be better to make "upstream" (maskym's branch) have
the same structure as gnu mach already has before even creating the
integration branch ?
<tschwinge> I though X15 is the upstream.
<braunr> maksym*
<braunr> the upstream was actually the userspace library, before x15 got
its own derived version
<tschwinge> OK, I see.
<tschwinge> Then we really don't care too much, and yes, you can put it all
in the right places right away.
<braunr> ok
<tschwinge> But is my approach understandable given there is an upstream
from which we may want to import later changes?
<tschwinge> given there *were*
<braunr> (fyi, the userspace code was merely a first step which purpose was
to eliminate as many bugs as possible and profile a little)
<braunr> i don't intend to maintain the userspace code, no
<braunr> and the x15 version already has some system specific changes that
don't apply to gnu mach
<tschwinge> OK, I understand.
<tschwinge> braunr: Then, what remains is essentially this:
<tschwinge> <tschwinge> Then, any bug fix patches that do not concern
salloc itself, should stay separately.
<tschwinge> <tschwinge> Also, any improvements that are not specific to
salloc itself.
<tschwinge> <tschwinge> All other salloc development commits (try this; no
this; fix other thing; etc.) can be combined into one commit on the
salloc branch.
<tschwinge> Right?
<braunr> ok
<braunr> hm, what about the history of maksym's branch ?
<tschwinge> braunr: We don't really need it, do we?
<tschwinge> If there are distinct commits that make sense to be kept
separate, then that is fine, but all the development commits can usually
be merged.
<tschwinge> ``squashed''
<braunr> i don't think we do, no
<braunr> ok so, i'll use his branch as a starting point in a private git
repository, until it's good enough to be merged upstream, then we'll
create the salloc integration branch and later merge that into master
<braunr> tschwinge: did i get it right ? :)
<tschwinge> We can still either keep Maksym's development branch open, or
perhaps create a tag named salloc-before-merge.
<tschwinge> Well, I think if we don't need to do the upstream-import thing,
then you can create a salloc integration branch right away, and prepare
everything in there.
<braunr> ok
<braunr> i'm not very familiar with remote branches
<tschwinge> OK. This way you don't need any.
<tschwinge> Just branch off of master (either your local master branch or
origin/master): git checkout -b salloc origin/master
<antrik> braunr: BTW, I'm not sure it has been clear, so let me restate it:
what large projects using Git usually do when merging new features
upstream is, they entirely drop the development history of the feature,
instead creating a new branch (or reworking the old one) which is
master-centric -- it is a series of commits, which get from the original
master to a state with the new feature implemented in the most
straightforward way
<braunr> antrik: in one commit ?
<braunr> antrik: or a few ofc
<antrik> depends. the commits should be bisectable as usual... i.e. don't
put things that can be separate into one commit, but don't separate
things that depend on each other into separate commits either :-)
<antrik> the bulk of the new code often goes in single large commit; but
the various changes to existing code necessary to make it work can often
make a pretty long series. but it can differ quite a lot depending on the
specific case
<antrik> just imagine you are someone reading the history in the future,
and tries to understand what changed while zalloc was replaced by
salloc. what series of commits makes this most obvious?
<braunr> sure
<braunr> antrik: new code first in a single commit first, then the
replacements from zalloc to salloc, then if any, special adjustements in
a third commit
<braunr> (ok twice first, remove one at will :p)
<antrik> yeah, something along these lines
<antrik> sometimes we also need praparation commits in advance, changing
the code structure so that the new feature can be added in a
straightforward fashion
<antrik> or cleanups afterwards
|
