On Sun, 27 Apr 2008 12:15:27 -0700 (PDT) Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > On Sun, 27 Apr 2008, Andrew Morton wrote: > > > > Now, I want to generate a plain patch against mainline which will add the > > patches which are in git-ia64 and which aren't in mainline. ie: when that > > patch is applied to mainline, we get git-ia64. Sounds simple. > > > > A naive > > > > git-diff origin git-ia64 > > Don't do that. > > That will diff between the two branches, and if they both contain stuff > (which they obviously do), you'll get all the things that are in origin > (but not git-ia64) as a reversed diff. > > What you _want_ is the diff from the last common point, aka the "merge > base". > > With git, you could do that as > > merge_base=$(git merge-base origin git-ia64) > git diff $merge_base git-ia64 > > but there is a convenient shorthand for that, which is to use "a...b" > (three dots!), so > > git diff -p --stat origin...git-ia64 > > should generally get you what you want. That generates no diff for several trees which I tried it on. And afaict from manual inspection, that's correct - they are empty. git-sched is non-empty: y:/usr/src/git26> cat .git/branches/git-sched git+ssh://master.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git#for-akpm and seems to dtrt too. But I'm pretty sure that the simple solutions were found wanting, but I don't recall why. I think it was because of a problem when git-netdev-all is based on git-net which is based on origin. I want to extract the git-net -> git-netdev-all diff, but doing that generates patches which reapply things which are already applied. iirc this happens when git-netdev-all is resynced with origin at a different time from when git-net is resynced with origin. I get hunks which reapply (or revert) changes which are in origin. But I don't presently have any trees which are based on other non-origin trees so I can't test that. > I say *generally*, because there might be multiple merge-bases if there > are crossing merges between the two branches and there is no well-defined > single common point. But that criss-cross case almost never happens for > the kernel, because I've been pretty good at trying to teach maintainers > to not generate that kind of complex history (it doesn't just obfuscate > the above kind of situation, it also makes gitk output harder-to-read than > it otherwise would be). > > That said, your script (that does a merge) should have been able to get > the diff too, and in fact handle even the criss-cross case. It's written a > bit strangely (like having that really old-fashioned way of using git > merge, passing in HEAD explicitly etc). Well. It is a couple of years old. I'll try the simple version later, see what happens. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
