Re: [PATCH 0/4] deterministic commit timestamps in tests

> Here's a revised patch (I see Junio already picked up the other fix; if
> that ends up being merged instead, that's not the end of the world).
>
> (compared to the earlier version, you can skip everything in the commit
> message before "One fix would be...").

> -- >8 --
> Subject: [PATCH] t9100: stop depending on commit timestamps
>
> The early part of t9100 creates an unusual "doubled" history in the
> "git-svn" ref. When we get to t9100.17, it looks like this:
>
>   $ git log --oneline --graph git-svn
>   [...]
>   *   efd0303 detect node change from file to directory #2
>   |\
>   * | 3e727c0 detect node change from file to directory #2
>   |/
>   *   3b00468 try a deep --rmdir with a commit
>   |\
>   * | b4832d8 try a deep --rmdir with a commit
>   |/
>   * f0d7bd5 import for git svn
>
> Each commit we make with "git commit" is paired with one from "git svn
> set-tree", with the latter as a merge of the first and its grandparent.
>
> Later, t9100.17 wants to check that "git svn fetch" gets the same trees.
> And it does, but just one copy of each. So it uses rev-list to get the
> tree of each commit and pipes it to "uniq" to drop the duplicates. Our
> input isn't sorted, but it will find adjacent duplicates. This works
> reliably because the order of commits from rev-list always shows the
> duplicates next to each other. For any one of those merges, we could
> choose to show its duplicate or the grandparent first. But barring
> clocks running backwards, the duplicate will always have a time equal to
> or greater than the grandparent. Even if equal, we break ties by showing
> the first-parent first, so the duplicates remain adjacent.
>
> But this would break if the timestamps stopped moving in chronological
> order. Normally we would rely on test_tick for this, but we have _two_
> sources of time here:
>
>   - "git commit" creates one commit based on GIT_COMMITTER_DATE (which
>     respects test_tick)
>
>   - the "svn set-tree" one is based on subversion, which does not have
>     an easy way to specify a timestamp
>
> So using test_tick actually breaks the test, because now the duplicates
> are far in the past, and we'll show the grandparent before the
> duplicate. And likewise, a proposed change to set GIT_COMMITTER_DATE in
> all scripts will break it.
>
> One fix would be to sort the list of trees before removing duplicates,
> but that loses information:
>
>   - we do care that the fetched history is in the same order
>
>   - there's a tree which appears twice in the history, and we'd want to
>     make sure that it's there both times
>
> So instead, let's de-duplicate using a hash (preserving the order), and
> drop only lines with identical trees and subjects (preserving the tree
> which appears twice, since it has different subjects each time).
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  t/t9100-git-svn-basic.sh | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
> index 9f2d19ecc4..3055943a22 100755
> --- a/t/t9100-git-svn-basic.sh
> +++ b/t/t9100-git-svn-basic.sh
> @@ -200,8 +200,9 @@ GIT_SVN_ID=alt
>  export GIT_SVN_ID
>  test_expect_success "$name" \
>      'git svn init "$svnrepo" && git svn fetch &&
> -     git rev-list --pretty=raw remotes/git-svn | grep ^tree | uniq > a &&
> -     git rev-list --pretty=raw remotes/alt | grep ^tree | uniq > b &&
> +     git log --format="tree %T %s" remotes/git-svn |
> +	awk "!seen[\$0]++ { print \$1, \$2 }" >a &&
> +     git log --format="tree %T" alt >b &&
>       test_cmp a b'
>  
>  name='check imported tree checksums expected tree checksums'