Re: New SCM and commit list

Chris Mason
2005-04-11T12:59:47Z

On Monday 11 April 2005 03:38, Ingo Molnar wrote:
> * Linus Torvalds <torvalds@osdl.org> wrote:
> > So anything that got modified in just one tree obviously merges to
> > that version. Any file that got modified in two trees will end up just
> > being passed to the "merge" program. See "man merge" and "man diff3".
> > The merger gets to fix up any conflicts by hand.
>
> at that point Chris Mason's "rej" tool is pretty nifty:
>
> ftp://ftp.suse.com/pub/people/mason/rej/rej-0.13.tar.gz
>
> (There is no fully automatic mode in where it would not bother the user
> with the really trivial rejects - but it has an automatic mode where you
> basically have to do nothing - maybe a fully automatic one could be
> added that would resolve low-risk rejects?)
>

rej -M skips the merge program, so rej -a -M will give you something like
this:

coffee:/local/linux.p # rej -a -M drivers/ide/ide.c.rej
drivers/ide/ide.c: 1 matched, 0 conflicts remain

But I would want to go over the bit that calculates the conflicts remaining
more carefully if people plan on trusting this ;) It'll run on unified diffs
too, although it will be slower then patch since the assumption is the quick
and easy placement patch does has already failed. (that's easy enough to fix
though).

> it's really easy to use (but then again i'm a vim user, so i'm biased),
> just try it on a random .rej file you have ("rej -a kernel/sched.c.rej"
> or whatever).

you can rej -m kdiff3|meld|tkdiff or any program that does a side by side
comparison of two files. (export REJMERGE=foo sets the diff prog as well)

I use rej frequently to merge patches in here, but that is mostly because
there is no easy way to get the common ancestor and parent revision of the
patches I'm merging.

With that info in hand, kdiff3 is pretty nice. You would have to spoon feed
it the renames, but it should have most of the other features you're looking
for, including the 'no gui if all conflicts are auto-solvable'

-chris