Re: [RFC PATCH] pack-refs: fail on falsely sorted packed-refs

From: SZEDER Gábor <szeder.dev@gmail.com>
Date: Feb 13, 2019, 10:56 UTC
Message-ID: <20190213105616.GH1622@szeder.dev>
In-Reply-To: <87lg2kj91a.fsf@evledraar.gmail.com>

On Wed, Feb 13, 2019 at 11:08:01AM +0100, Ævar Arnfjörð Bjarmason wrote:

> 
> On Thu, Jan 31 2019, Max Kirillov wrote:

Show 7 quoted lines

> >  refs/packed-backend.c               | 15 +++++++++++++++
> >  t/t3212-pack-refs-broken-sorting.sh | 26 ++++++++++++++++++++++++++
> >  2 files changed, 41 insertions(+)
> >  create mode 100755 t/t3212-pack-refs-broken-sorting.sh
> 
> This is not an area I'm very familiar with. So mostly commeting on
> cosmetic issues with the patch.

Just two quick comments in addition to Ævar's:

Show 6 quoted lines

> > @@ -1137,6 +1138,20 @@ static int write_with_updates(struct packed_ref_store *refs,
> >  		struct ref_update *update = NULL;
> >  		int cmp;
> >
> > +		if (iter)
> > +		{

According to our CodingGuidelines, the opening bracket should go on the same line as the condition, i.e.

  if (iter) {

Show 30 quoted lines

> > diff --git a/t/t3212-pack-refs-broken-sorting.sh b/t/t3212-pack-refs-broken-sorting.sh
> > new file mode 100755
> > index 0000000000..37a98a6fb1
> > --- /dev/null
> > +++ b/t/t3212-pack-refs-broken-sorting.sh
> > @@ -0,0 +1,26 @@
> > +#!/bin/sh
> > +
> > +test_description='tests for the falsely sorted refs'
> > +. ./test-lib.sh
> > +
> > +test_expect_success 'setup' '
> > +	git commit --allow-empty -m commit &&
> 
> Looks like just "test_commit A" would do here.
> 
> > +	for num in $(test_seq 10)
> > +	do
> > +		git branch b$(printf "%02d" $num) || break
> > +	done &&
> 
> We can fail in these sorts of loops. There's a few ways to deal with
> that. Doing it like this with "break" will still silently hide errors:
> 
>     $ for i in $(seq 1 3); do if test $i = 2; then false || break; else echo $i; fi; done && echo success
>     1
>     success
> 
> One way to deal with that is to e.g. before the loop say "had_fail=",
> then set "had_fail=t" in that "||" case, and test for it after the loop.

No, you can simply do 'cmd1 && cmd2 || return 1' in the body of the for loop; that's why we have a separate test_eval_inner() helper function in test-lib.