This behavior of git-rev-parse is observed since git 1.8.3.1 at least(*), and likely earlier versions. At least one git-reliant project in-the-wild relies on this current behavior of git-rev-parse being able to handle multiple --since= arguments without squeezing identical results together. So add a test to prevent the potential for regression in downstream projects. (*) 1.8.3.1 the version packaged for CentOS 7.x Signed-off-by: Eric Wong <e@xxxxxxxxx> --- Said git-reliant project does use allow /optional/ use of libgit2 via Perl Inline::C; but libgit2's git__date_parse() isn't part of the public API; and it's unlikely anybody using CentOS 7.x would run the latest libgit2 even if it were added today. t/t1500-rev-parse.sh | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh index abdda360d5..deae916707 100755 --- a/t/t1500-rev-parse.sh +++ b/t/t1500-rev-parse.sh @@ -243,4 +243,19 @@ test_expect_success 'showing the superproject correctly' ' test_cmp expect out ' +# at least one external project depends on this behavior: +test_expect_success 'rev-parse --since= unsqueezed ordering' ' + x1=--since=1970-01-01T00:00:01Z && + x2=--since=1970-01-01T00:00:02Z && + x3=--since=1970-01-01T00:00:03Z && + git rev-parse $x1 $x1 $x3 $x2 >actual && + cat >expect <<-EOF && + --max-age=1 + --max-age=1 + --max-age=3 + --max-age=2 + EOF + test_cmp expect actual +' + test_done
