Hi! On Fri, 19 Sep 2014, Tom Wijsman wrote: > On Thu, 18 Sep 2014 19:39:08 +0200 > Tobias Klausmann <klaus...@gentoo.org> wrote: > > > 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. > > The concept of rebasing your commits has been invented for this. In the > less common case that multiple people change the keywords, a manual > three way merge is a breeze; taking into consideration that maintainers > should be aware of KEYWORDS and other recent changes to their packages.
As I pointed out, getting the right code into the tree is not the problem here. It is extra work over the current way of doing it (since I need to deal with a local commit that can't be ff'd or rebased as git is very line-oriented. On top of the extra work, there have been several mentions that only meaning ful merge-commits are wanted in the tree (or not wanted at all). AIUI, avoiding them in the keywording/stabilizing phase is currently very difficult, unless we split KEYWORDS into separate lines or find another mechanism (like having the maintainer/keyword-requestor do all the edits after the archs sign off on them). I'd be delighted to hear a simpler solution that only involves doing the semantic merge (like we do now with CVS). And at least in my case, collisions during keywording are fairly common, and will be even more so with git since fetch/pull are slower than for a CVS subdir (since git checks the whole tree for local changes, not just the current subtree, AIUI). Again, correct me if I'm wrong. I've been using git for ~4 years, but only in single-developer mode. And even there I managed to make a mess of repo histories :-/ Fortunately, nobody cares about my stuff. Regards, Tobias
