[PATCH] Fix for git-rev-list --merge-order B ^A (A,B share common base) [rev 2]
commit99c2bc93000dfadc3ac26ddced23e50520cf30d0
authorJon Seymour <jon.seymour@gmail.com>
Thu, 30 Jun 2005 01:51:34 +0000 (30 11:51 +1000)
committerLinus Torvalds <torvalds@ppc970.osdl.org>
Thu, 30 Jun 2005 03:53:10 +0000 (29 20:53 -0700)
tree6f7bdf5740f757d49d02a16ea691e6093373e60c
parentda4b932a0c5b249694216b1580b7bc2ded9e0280
[PATCH] Fix for git-rev-list --merge-order B ^A (A,B share common base) [rev 2]

This patch makes --merge-order produce the same list as git-rev-list
without --merge-order specified.

In particular, if the graph looks like this:

A
| B
|/
C
|
D

The both git-rev-list B ^A and git-rev-list --merge-order will produce B.

The unit tests have been changed to reflect the fact that the prune
points are now formally part of the start list that is used to perform
the --merge-order sort.

That is: git-rev-list --merge-order A ^D used to produce

= A
| C

It now produces:

^ A
| C

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
epoch.c
t/t6001-rev-list-merge-order.sh