On 2019-10-08 at 12:33:43, Bert Wesarg wrote:
> On Tue, Oct 8, 2019 at 2:21 PM Derrick Stolee <stolee@gmail.com> wrote:
> >
> > 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?

This is completely correct, and, yes, I can definitely make that change.
In fact, the fact that this is confusing probably means I should use a
suitably named shell function for this, so I'll make that change when I
reroll.

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

I would normally use echo for these types of things (because that's our
style and it's more customary), but in this case the symlink contents
don't contain a newline, so printf is required.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204