Re: [PATCH 0/4] deterministic commit timestamps in tests
- From
- Eric Wong <e@80x24.org>
- Date
- Jul 14, 2020, 21:47 UTC
- Message-ID
- <20200714214728.GA21660@dcvr>
- In-Reply-To
- <20200714123334.GB2587001@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
Show 14 quoted lines
> On Tue, Jul 14, 2020 at 08:31:42AM -0400, Jeff King wrote:
>
> > We _could_ fix this by sorting before removing duplicates, but
> > presumably it's a useful part of the test to make sure the trees appear
> > in the same order in both spots. Likewise, we could use something like:
> >
> > perl -ne 'print unless $seen{$_}++'
> >
> > to remove duplicates without impacting the order. But that doesn't work
> > either, because there are actually multiple (non-duplicate) commits with
> > the same trees (we change a file mode and then change it back). So we'd
> > actually have to de-duplicate the combination of subject and tree. Which
> > then further throws off t9100.18, which compares the tree hashes
> > exactly; we'd have to strip the result back down.Right, log order matters, so sorting isn't ideal.
Show 17 quoted lines
> Actually, that last one isn't _too_ bad. It looks something like this:
>
> diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
> index b80952f0ac..4502c5f97d 100755
> --- a/t/t9100-git-svn-basic.sh
> +++ b/t/t9100-git-svn-basic.sh
> @@ -204,8 +204,10 @@ 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 |
> + perl -lne "print unless \$seen{\$_}++" |
> + cut -d" " -f1-2 >a &&
> + git log --format="tree %T" remotes/alt >b &&
> test_cmp a b'The future of non-strict one-liners with Perl7 on the horizon seems uncertain :< cut is unnecessary either way, but I suggest awk, here:
awk "!seen[\$0]++ { print \$1, \$2 }'Show 7 quoted lines
> name='check imported tree checksums expected tree checksums' > > It does lose a little bit of information, which is that in the original > we confirmed that the duplicates were always next to each other. But I'm > not sure that's important. We'd get confused if the same subject > appeared twice, but all of the commits have distinct hard-coded > subjects in the earlier tests.
Yeah, but I think it's fine. It's been a while since I wrote this