Re: [PATCH 07/15] t4011: abstract away SHA-1-specific constants

From: Bert Wesarg <bert.wesarg@googlemail.com>
Date: Oct 8, 2019, 12:33 UTC
Message-ID: <CAKPyHN3NaBv5s9aefb8fTDeGto2tLyTa0DxTjbWO9pGRY22pPQ@mail.gmail.com>
In-Reply-To: <4733b8a0-bfd9-a49a-01d2-1c9f2a48cdf8@gmail.com>

On Tue, Oct 8, 2019 at 2:21 PM Derrick Stolee <stolee@gmail.com> wrote:

Show 18 quoted lines

>
> On 10/5/2019 5:12 PM, brian m. carlson wrote:
> > Adjust the test so that it computes variables for object IDs instead of
> > using hard-coded hashes.
>
> [snip]
>
> > @@ -137,14 +141,17 @@ test_expect_success SYMLINKS 'setup symlinks with attributes' '
> >  '
> >
> >  test_expect_success SYMLINKS 'symlinks do not respect userdiff config by path' '
> > -     cat >expect <<-\EOF &&
> > +     file=$(git rev-parse --short $(git hash-object file.bin)) &&
> > +     link=$(git rev-parse --short \
> > +             $(printf file.bin | git hash-object --stdin)) &&
>
> Why this change from $(git hash-object file.bin) to
> $(printf file.bin | git hash-object --stdin)?

thats two different things. The first hashes the content of file "file.bin". The second hashes the literal string "file.bin". To avoid this confusion, may I suggest to use 'printf "%s" "file.bin"', so that it is clear, that the literal string is meant in this context?

Bert

Show 6 quoted lines

>
> For that matter, why are you using the "printf|git hash-object"
> pattern throughout your change? Seems like an unnecessary hurdle
> to me.
>
> -Stolee