On Fri, 19 Sep 2014 16:03:57 +0200 Tobias Klausmann <klaus...@gentoo.org> wrote:
> 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. It can be rebased when you use branches, which is less line-oriented; yeah, that indeed is extra work over plain single commit. This can be improved with shell aliases or functions, to spare out on key presses... > 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). Not a problem when you rebase. > I'd be delighted to hear a simpler solution that only involves > doing the semantic merge (like we do now with CVS). Create one or two shell aliases or functions for pulling that do: 1) stashes your local modifications 2) create a new branch with your local commits 3) reset the master branch to the last upstream commit 4) pulls new changes into the master branch 5) rebases your new branch onto master 6) remove the master branch and rename your new branch to it 7) applies the stash from step (1) Given that the rebase is interactive, 1-5 and 5-7 will probably be separate shell aliases or functions; nonetheless, this takes away a ton of manual typing giving you more time for where the actual work is. I would advise against this automation for other projects; but given the plain single commit nature we're used to, this works for Portage tree. > 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). Has this been experimented with? Is the Portage tree that big? Afaik Git does a lot to be fast, whereas I experience CVS to be slow; I would be surprised if Git were to be slower than faster compared to CVS. > 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. Reading into Git workflows and documentation about stashing, rebasing, ... can make a world of difference to turn mess into a gem.
