Re: my git problem

[Andrew Morton <akpm@linux-foundation.org>]

On Sun, 27 Apr 2008 12:15:27 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> 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.