[PATCHv2 0/2] merge-tree: fix (merge-base a b) b a

[Will Palmer <wmpalmer@gmail.com>]

This series notes, then fixes, a regression introduced by
15b4f7a68d8c3c8ee28424415b203f61202d65d1 /
	merge-tree: use ll_merge() not xdl_merge()

I don't know the proper terminology to describe what's being fixed here.
This seems to most-easily be triggered by (for example):
	git merge-tree $(git merge-base HEAD @{u}) HEAD @{u}

In the git repository at the moment, this could be triggered with:
	git merge-tree $(git merge-base origin/next origin/master) \
		origin/next origin/master

Though as I write this, next has only just been merged with master, so
that is not the case. For an example which is less likely to go away,
try:
	git merge-tree c9eaaab4165d8f402930d12899ec097495b599e6 \
		be16ac8cc8ce693c6adf37b80db65d10a41b4eb9 \
		9918285fb10d81af9021dae99c5f4de88ded497c

It's actually very trivial to reproduce this, to the point where I
can't help but wonder how much merge-tree is actually being used. As
I narrowed the test-case more and more, I was surprised by how little
it took to trigger it. The first patch in this series includes some
very basic tests for merge-tree, the last of which demonstrates the
regression.

The second patch implements the trivial fix for it.

This is the second version of the patch. The first version of the patch
included very trivial tests for merge-tree, which were really only
intended to demonstrate the breakage being fixed. This version of the
patch includes proper tests, with real "expected vs actual" testing,
rather than dumb "did it return successfully?" checks.

Will Palmer (2):
  add basic tests for merge-tree
  fix merge-tree where two branches share no changes

 builtin/merge-tree.c  |    3 +-
 t/t4300-merge-tree.sh |  277 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 279 insertions(+), 1 deletions(-)
 create mode 100755 t/t4300-merge-tree.sh

-- 
1.7.1.703.g42c01