Re: my git problem

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Apr 27, 2008, 20:24 UTC
Message-ID: <alpine.LFD.1.10.0804271315010.3119@woody.linux-foundation.org>
In-Reply-To: <20080427124454.6a606305.akpm@linux-foundation.org>

On Sun, 27 Apr 2008, Andrew Morton wrote:

Show 6 quoted lines

> 
> 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.

Well, if a tree has patches that are already applied up-stream, then yes, you do actually have to do the merge in order to see that. Because obviously the diff is in two places, and if they merge cleanly, one of them has to be made to not count.

So it depends on what you want.

	git diff a...b

says literally "what has been added to 'b' since it diverged from 'a'".

That is a useful and valid thing to ask, but it is very fundamentally also *not* the same thing as actually doing the merge, and asking what the merge added. Doing

	git merge --no-commit otherbranch
	git diff HEAD > diff
	git reset --hard

will do that: it will do the merge (which obviously squashes any diffs that existed in the other tree as different commits), and then diffs the HEAD against that resulting state.

So they are two fundamentally different things to do.

In some sense, the "git diff a...b" is closer to your "series of quilt patches" model, in that it just generates a patch - which may obviously conflict with the *other* patches you are also generating. It would then expect your quilt logic to do some sane patch merging.

Of course, we know that quilt doesn't do sane patch merging, so you are probably better off with the second version: letting git merge for you, and taking the resulting diff.

> But I don't presently have any trees which are based on other non-origin
> trees so I can't test that.

Yes, in that case you'll only get issues when somebody commits the same patch I have already applied. Which does happen, of course.

			Linus