On Sun, 27 Apr 2008 13:24:08 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:

quoted text
> 
> 
> On Sun, 27 Apr 2008, Andrew Morton wrote:
> > 
> > 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.
> 

hm, weirdness.

y:/usr/src/git26> git-diff origin...git-ia64   
y:/usr/src/git26> git-log origin...git-ia64 | wc -l
15574

I'd have expected git-log to operate on the same patches as git-diff.

I'm sure there's a logical explanation for this ;)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html