1 |
On Fri, 19 Sep 2014 16:03:57 +0200 |
2 |
Tobias Klausmann <klausman@g.o> wrote: |
3 |
|
4 |
> As I pointed out, getting the right code into the tree is not the |
5 |
> problem here. It is extra work over the current way of doing it |
6 |
> (since I need to deal with a local commit that can't be ff'd or |
7 |
> rebased as git is very line-oriented. |
8 |
|
9 |
It can be rebased when you use branches, which is less line-oriented; |
10 |
yeah, that indeed is extra work over plain single commit. This can be |
11 |
improved with shell aliases or functions, to spare out on key presses... |
12 |
|
13 |
> On top of the extra work, there have been several mentions that |
14 |
> only meaning ful merge-commits are wanted in the tree (or not |
15 |
> wanted at all). AIUI, avoiding them in the keywording/stabilizing |
16 |
> phase is currently very difficult, unless we split KEYWORDS into |
17 |
> separate lines or find another mechanism (like having the |
18 |
> maintainer/keyword-requestor do all the edits after the archs |
19 |
> sign off on them). |
20 |
|
21 |
Not a problem when you rebase. |
22 |
|
23 |
> I'd be delighted to hear a simpler solution that only involves |
24 |
> doing the semantic merge (like we do now with CVS). |
25 |
|
26 |
Create one or two shell aliases or functions for pulling that do: |
27 |
|
28 |
1) stashes your local modifications |
29 |
2) create a new branch with your local commits |
30 |
3) reset the master branch to the last upstream commit |
31 |
4) pulls new changes into the master branch |
32 |
5) rebases your new branch onto master |
33 |
6) remove the master branch and rename your new branch to it |
34 |
7) applies the stash from step (1) |
35 |
|
36 |
Given that the rebase is interactive, 1-5 and 5-7 will probably be |
37 |
separate shell aliases or functions; nonetheless, this takes away a ton |
38 |
of manual typing giving you more time for where the actual work is. |
39 |
|
40 |
I would advise against this automation for other projects; but given the |
41 |
plain single commit nature we're used to, this works for Portage tree. |
42 |
|
43 |
> And at least in my case, collisions during keywording are fairly |
44 |
> common, and will be even more so with git since fetch/pull are |
45 |
> slower than for a CVS subdir (since git checks the whole tree for |
46 |
> local changes, not just the current subtree, AIUI). |
47 |
|
48 |
Has this been experimented with? Is the Portage tree that big? Afaik |
49 |
Git does a lot to be fast, whereas I experience CVS to be slow; I would |
50 |
be surprised if Git were to be slower than faster compared to CVS. |
51 |
|
52 |
> Again, correct me if I'm wrong. I've been using git for ~4 years, |
53 |
> but only in single-developer mode. And even there I managed to |
54 |
> make a mess of repo histories :-/ Fortunately, nobody cares about |
55 |
> my stuff. |
56 |
|
57 |
Reading into Git workflows and documentation about stashing, |
58 |
rebasing, ... can make a world of difference to turn mess into a gem. |