patches/merge-tree-regression/v1

From 645875f209b597aad88815ad6bb678b862e5f566 Mon Sep 17 00:00:00 2001
From: Will Palmer <wmpalmer@gmail.com>
Date: Sat, 10 Jul 2010 01:29:35 +0100
Subject: [PATCH 0/2] merge-tree: fix (merge-base a b) b a

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.

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 |   43 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+), 1 deletions(-)
 create mode 100755 t/t4300-merge-tree.sh

--
1.7.1.703.g42c01