1 |
>>>>> On Thu, 18 Sep 2014, Tobias Klausmann wrote: |
2 |
|
3 |
> However, one aspect of how ebuilds are written these days will |
4 |
> cause a non-trivial amount of merge commits that are not actually |
5 |
> useful in that sense. |
6 |
|
7 |
> This is due to the way keywording and stabilization work on an |
8 |
> ebuild level. Since keywords are all in one line, any merge tool |
9 |
> will barf on two keywords being changed in disparate clones. I.e. |
10 |
> if I change ~alpha->alpha while someone else changes |
11 |
> ~amd64->amd64, we will have a merge conflict. |
12 |
|
13 |
> There several approaches to this problem: |
14 |
|
15 |
> 1) Make a merge commit as explained above. Aside from the |
16 |
> not really useful merge commit, this also means manual work for |
17 |
> the ATs, who could really do with less manual labor. |
18 |
|
19 |
> 2) roll back the local commit, fetch and re-do the semantically |
20 |
> equivalent commit. This might be automated, but someone has to |
21 |
> actually write that code. |
22 |
|
23 |
> 3) Do away with one-line KEYWORD lists. This has wide-ranging |
24 |
> repercussions, from grepping-and-parsing (which is already broken |
25 |
> in different ways[0]), and it makes the "preamble" of ebuilds |
26 |
> longer. |
27 |
|
28 |
If this should really turn out to be a problem, then we could also: |
29 |
|
30 |
4) Replace git's default merge driver by our own one that is better |
31 |
suited for ebuilds. This can be done per repository via .git/config |
32 |
and .gitattributes. |
33 |
|
34 |
Ulrich |