Hi!
Since we're causing at least mild upheaval process-wise, I
thought I'd bring up a topic that will be exacerbated by the git
migration if it's not really addressed.
AIUI, we try to avoid merge conflicts, unless the merge is a
meaningful integration of divergent processes.
However, one aspect of how ebuilds are written these days will
cause a non-trivial amount of merge commits that are not actually
useful in that sense.
This is due to the way keywording and stabilization work on an
ebuild level. Since keywords are all in one line, any merge tool
will barf on two keywords being changed in disparate clones. I.e.
if I change ~alpha->alpha while someone else changes
~amd64->amd64, we will have a merge conflict.
There several approaches to this problem:
1) Make a merge commit as explained above. Aside from the
not really useful merge commit, this also means manual work for
the ATs, who could really do with less manual labor.
2) roll back the local commit, fetch and re-do the semantically
equivalent commit. This might be automated, but someone has to
actually write that code.
3) Do away with one-line KEYWORD lists. This has wide-ranging
repercussions, from grepping-and-parsing (which is already broken
in different ways[0]), and it makes the "preamble" of ebuilds
longer.
The fundamental problem is of course that most diff/merge
algorithms are line-oriented. If two commits change the same
single line, both CVS and git are unhappy and yell for human
intervention. The difference with git is that the commit(s) that
introduced the change need to be rolled back and semantically
re-applied, whereas CVS just puts conflict markers nto the file
for me to sort (extra work, but much less than
rollback+hand-merge) and the lets me commit.
In essence, the local-vs-remote history discrepancy does not
exist with CVS, and in git it requires extra manual work to
resolve[1].
In any case, this needs to be addressed in _some_ way.
Regards,
Tobias
[0] Think conditional keywords, like:
if something; then
KEYWORDS=this
else
KEYWORDS=that
fi
This is already in the tree and breaks the grep/scripting
assumption, so it's a weak argument.
[1] As I mentioned, this extra work is scriptable, but that needs
to be done and the process for ATs needs to be amended to explain
this situation.
--
Sent from aboard the Culture ship
GCU (Ridge Class) Jaundiced Outlook
