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