Re: my git problem
- From
- Andrew Morton <akpm@linux-foundation.org>
- Date
- Apr 27, 2008, 19:44 UTC
- Message-ID
- <20080427124454.6a606305.akpm@linux-foundation.org>
- In-Reply-To
- <alpine.LFD.1.10.0804271204510.3119@woody.linux-foundation.org>
On Sun, 27 Apr 2008 12:15:27 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 32 quoted lines
> > > 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.
Show 12 quoted lines
> 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.