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
--
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