tree c70c61b3eb86661cddc4220099a86ddde834315f
parent 3259a960217f1dd44c46007a545f473bd575f951
author Adithya Chakilam <achakila@codeaurora.org> 1611970504 -0600
committer Matthias Sohn <matthias.sohn@sap.com> 1612696188 -0500

Fix DateRevQueue tie breaks with more than 2 elements

DateRevQueue is expected to give out the commits that have higher
commit time. But in case of tie(same commit time), it should give
the commit that is inserted first. This is inferred from the
testInsertTie test case written for DateRevQueue. Also that test
case, right now uses just two commits which caused it not to fail
with the current implementation, so added another commit to make
the test more robust.

By fixing the DateRevQueue, we would also match the behaviour of
LogCommand.addRange(c1,c2) with git log c1..c2. A test case for
the same is added to show that current behaviour is not the
expected one.

By fixing addRange(), the order in which commits are applied during
a rebase is altered. Rebase logic should have never depended upon
LogCommand.addRange() since the intended order of addRange() is not
the order a rebase should use. So, modify the RebaseCommand to use
RevWalk directly with TopoNonIntermixSortGenerator.

Add a new LogCommandTest.addRangeWithMerge() test case which creates
commits in the following order:

         A - B - C - M
              \     /
                -D-

Using git 2.30.0, git log B..M outputs:  M C D
LogCommand.addRange(B, M) without this fix outputs: M D C
LogCommand.addRange(B, M) with this fix outputs: M C D

Change-Id: I30cc3ba6c97f0960f64e9e021df96ff276f63db7
Signed-off-by: Adithya Chakilam <achakila@codeaurora.org>