1 |
Hi! |
2 |
|
3 |
On Fri, 19 Sep 2014, hasufell wrote: |
4 |
> Tobias Klausmann: |
5 |
> >>> If this should really turn out to be a problem, then we could also: |
6 |
> >>> |
7 |
> >>> 4) Replace git's default merge driver by our own one that is better |
8 |
> >>> suited for ebuilds. This can be done per repository via .git/config |
9 |
> >>> and .gitattributes. |
10 |
> >> |
11 |
> >> Certainly that would be even more helpful! |
12 |
> > |
13 |
> > Still, all of these scenarios cause merge commits |
14 |
> |
15 |
> No. |
16 |
> |
17 |
> 1. git pull --rebase=preserve origin master |
18 |
> => error: could not apply <commit>... <commit-msg> |
19 |
> 2. fix conflicts via 'git mergetool' (e.g. meld or vimdiff with 3 panel |
20 |
> view... very easy to see what happened) |
21 |
> 3. finish rebase via 'git rebase --continue' |
22 |
> => your unpushed keyword commit has been rewritten without a merge commit |
23 |
> 4. push |
24 |
|
25 |
See, this is why I asked: I was not aware of this (and have |
26 |
pointed out repeatedly that I'd be delighted to be educated). |
27 |
|
28 |
> That is pretty easy and takes you ~20s for a keyword merge. |
29 |
> What's the problem? |
30 |
|
31 |
The problem is that not everyone has deep knowledge of git. I |
32 |
asked because I wanted to know what (if anything) we can do about |
33 |
a problem I perceived. When we do the migration, there _will_ be |
34 |
confusion and breakage and those who actually have deep knowledge |
35 |
will likely cringe a lot. Documentation is the way out of that. |
36 |
|
37 |
Regards, |
38 |
Tobias |
39 |
|
40 |
-- |
41 |
printk("Penguin %d is stuck in the bottle.\n", i); |
42 |
linux-2.0.38/arch/sparc/kernel/smp.c |