Linus TorvaldsOk, this doesn't come up in real life very much, but it's not impossible, and I was generating this test-case to show Al how it's probably going to be a real bitch to teach 'patch' how to handle git rename patches (or git copy patches) in the general case.
Of course, the way git patches work is that the same source file may show up several times (due to copies) or as both a source and a destination (criss-cross renames or just rename + create new file), and we always look at the _original_ state when we apply a patch fragment. Which makes it hard for something like GNU "patch" that is purely linear.
And I was going to send Al an example of git doing that, and I was sure that we had handled this at some point, but maybe I'm just wrong. I didn't really go back and test it.
The point is, git itself fails here. Although not for any really fundamental reason - but simply because we are a bit too tight on some error handling, and do some checks wrong.
Git can _generate_ criss-cross merges correctly (although you have to use the -B flag to make git try to break the names up):
mv kernel/sched.c a mv kernel/exit.c kernel/sched.c mv a kernel/exit.c git diff -B -M > diff
and we get a nice correct diff:
diff --git a/kernel/sched.c b/kernel/exit.c similarity index 100% rename from kernel/sched.c rename to kernel/exit.c diff --git a/kernel/exit.c b/kernel/sched.c similarity index 100% rename from kernel/exit.c rename to kernel/sched.c
but if you actually try to apply such a patch, we fail miserably (you need to got a 'git reset --hard' or similar to get back the original tree to apply the diff on, obviously):
[torvalds@nehalem linux]$ git apply diff error: kernel/exit.c: already exists in working directory error: kernel/sched.c: already exists in working directory
which is really sad.
I don't have a patch for it, and I don't think it's a huge deal in practice, but I do think it's seriously wrong how we can generate a diff that we then refuse to apply.
Linus
