Re: [PATCH v4 1/4] t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs

Alexey Shumkin [off-list ref] writes:

quoted

Why do we want "whatever_7" variables and use "cut -c1-7" to produce
them?  Is "7" something we care deeply about?

I think what we care a lot more than "7" that happens to be the
current default value is to make sure that, if we ever update the
default abbreviation length to a larger value, the abbreviation
shown with --format=%h is consistent with the abbreviation that is
given by rev-parse --short.

    head1_short=$(git rev-parse --short $head1)

perhaps?
...
Likewise.

quoted

+	tree2_7=$(echo $tree2 | cut -c1-7)

Likewise.

but is there "git something" to return abbreviated tree hash except
"pretty formats" that is implicitly tested here?

Does "git rev-parse --short $tree2" count?

Alexey Shumkin [off-list ref] writes:

quoted

quoted

Why do we want "whatever_7" variables and use "cut -c1-7" to
produce them?  Is "7" something we care deeply about?

I think what we care a lot more than "7" that happens to be the
current default value is to make sure that, if we ever update the
default abbreviation length to a larger value, the abbreviation
shown with --format=%h is consistent with the abbreviation that is
given by rev-parse --short.

    head1_short=$(git rev-parse --short $head1)

perhaps?
...
Likewise.

quoted

+	tree2_7=$(echo $tree2 | cut -c1-7)

Likewise.

but is there "git something" to return abbreviated tree hash except
"pretty formats" that is implicitly tested here?

Does "git rev-parse --short $tree2" count?

Oops! Yep!