Messages in this thread | | | Date | Wed, 4 Jun 2014 16:12:50 -0700 | Subject | Re: [GIT pull] irq core changes for 3.16 | From | Linus Torvalds <> |
| |
On Wed, Jun 4, 2014 at 12:34 PM, Thomas Gleixner <tglx@linutronix.de> wrote: > > Is what my script uses for years now, but this time it created a diff > with random extra content from all over the tree. > > $BASE is 2ed9fd28c2884e9f41c133f86a7e377d7c0a96bf
You have criss-cross merges, so there are multiple merge-bases. You can see if it you use the "--all" flag to "git merge-base". For example, there's that "Merge branches 'linus' and 'irq/urgent' into irq/core" that does a back-merge of my tree, and there's also a "Merge tag 'irqchip-mvebu-3.16' of git://git.infradead.org/linux-mvebu into irq/core" that merges stuff that is already in my tree. So there is not a single unique shared base-point.
When that happens, doing the diff against one of the base points *can* happen to work, but generally gives other random cruft from the other shared part of the tree as part of the diff. It happened for your timer core pull too, you just didn't notice because the shared part was much smaller.
Anyway, for the "there are multiple different commits in common" case, the only way to get a true diff is to generate the actual merge in a temporary branch, and see what the result is (and then just throw away the merge). The git merge facilities are much smarter than just diffing between two points, and will actually recursively merge up the different base points in order to generate the final merge result.
But if it's rare, it doesn't much matter if the trivial "let's just diff against the base" doesn't always work. But this *is* one of the reasons why I suggest against back-merges, because it makes the history harder to figure out, and it causes these kinds of "there are many different independent base points" issues.
Linus
| |