1 |
Hi! |
2 |
|
3 |
Since we're causing at least mild upheaval process-wise, I |
4 |
thought I'd bring up a topic that will be exacerbated by the git |
5 |
migration if it's not really addressed. |
6 |
|
7 |
AIUI, we try to avoid merge conflicts, unless the merge is a |
8 |
meaningful integration of divergent processes. |
9 |
|
10 |
However, one aspect of how ebuilds are written these days will |
11 |
cause a non-trivial amount of merge commits that are not actually |
12 |
useful in that sense. |
13 |
|
14 |
This is due to the way keywording and stabilization work on an |
15 |
ebuild level. Since keywords are all in one line, any merge tool |
16 |
will barf on two keywords being changed in disparate clones. I.e. |
17 |
if I change ~alpha->alpha while someone else changes |
18 |
~amd64->amd64, we will have a merge conflict. |
19 |
|
20 |
There several approaches to this problem: |
21 |
|
22 |
1) Make a merge commit as explained above. Aside from the |
23 |
not really useful merge commit, this also means manual work for |
24 |
the ATs, who could really do with less manual labor. |
25 |
|
26 |
2) roll back the local commit, fetch and re-do the semantically |
27 |
equivalent commit. This might be automated, but someone has to |
28 |
actually write that code. |
29 |
|
30 |
3) Do away with one-line KEYWORD lists. This has wide-ranging |
31 |
repercussions, from grepping-and-parsing (which is already broken |
32 |
in different ways[0]), and it makes the "preamble" of ebuilds |
33 |
longer. |
34 |
|
35 |
The fundamental problem is of course that most diff/merge |
36 |
algorithms are line-oriented. If two commits change the same |
37 |
single line, both CVS and git are unhappy and yell for human |
38 |
intervention. The difference with git is that the commit(s) that |
39 |
introduced the change need to be rolled back and semantically |
40 |
re-applied, whereas CVS just puts conflict markers nto the file |
41 |
for me to sort (extra work, but much less than |
42 |
rollback+hand-merge) and the lets me commit. |
43 |
|
44 |
In essence, the local-vs-remote history discrepancy does not |
45 |
exist with CVS, and in git it requires extra manual work to |
46 |
resolve[1]. |
47 |
|
48 |
In any case, this needs to be addressed in _some_ way. |
49 |
|
50 |
Regards, |
51 |
Tobias |
52 |
|
53 |
[0] Think conditional keywords, like: |
54 |
if something; then |
55 |
KEYWORDS=this |
56 |
else |
57 |
KEYWORDS=that |
58 |
fi |
59 |
|
60 |
This is already in the tree and breaks the grep/scripting |
61 |
assumption, so it's a weak argument. |
62 |
|
63 |
[1] As I mentioned, this extra work is scriptable, but that needs |
64 |
to be done and the process for ATs needs to be amended to explain |
65 |
this situation. |
66 |
|
67 |
-- |
68 |
Sent from aboard the Culture ship |
69 |
GCU (Ridge Class) Jaundiced Outlook |