On Sun, 27 Apr 2008 13:24:08 -0700 (PDT) Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
