* Linus Torvalds <[email protected]> wrote:
> Then the bad news: the merge algorithm is going to suck. It's going to
> be just plain 3-way merge, the same RCS/CVS thing you've seen before.
> With no understanding of renames etc. I'll try to find the best parent
> to base the merge off of, although early testers may have to tell the
> piece of crud what the most recent common parent was.
>
> 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
it gets the trivial rejects right, and is pretty powerful to quickly
cycle through the nontrivial ones too. It shows the old and new code
side by side too, etc.
(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?)
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).
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
