Strange behavior of git rev-list --first-parent --ancesty-path

Hello! Imagine following tree: A--B--C \ / D--E B is parent #1 of C. git rev-list --first-parent --ancestry-path D..C returns zero commits. This is correct, since one cannot find any commits between D and C traversing tree by first parent. git rev-list --first-parent --ancestry-path E..C

[no subject]

help -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] merge-base: fix duplicates and not best ancestors in output

--octopus: reduce the result from get_octopus_merge_bases() Scripts that use merge-base --octopus could do the reducing themselves, but most of them are expected to want to get the reduced results without having to do any work themselves. Tests are taken from a message by Василий Макаров

[PATCH 1/2] merge-base: fix duplicates and not best ancestors in output

Hi there! First of all: I'm new to mailing-lists, sorry if I'm doing it wrong. I've found a bug in git merge-base, causing it to show not best common ancestors and duplicates under some circumstances (example is given in attached test case). Problem cause is algorithm used in

[PATCH 2/2] t6010: add test to git merge-base --all --octopus

And here is the test: with git 1.8.5.2 this test don't pass because of git merge-base may return duplicates and incorrect set of bases (not best common ancestors) --- t/t6010-merge-base.sh | 39 +++ 1 file changed, 39 insertions(+) diff --git