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

> 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?
> 
> > +	echo changed >foo &&
> > +	git commit -a -m "changed foo" &&
> > +	head2=$(git rev-parse --verify HEAD) &&
> > +	head2_7=$(echo $head2 | cut -c1-7) &&
> > +	head2_parent=$(git cat-file -p HEAD | grep parent | cut -f
> > 2 -d" ") &&
> 
> Do not use "cat-file -p" that is for human consumption in scripts,
> unless you are testing how the format for human consumption should
> look like (we may later add more pretty-print to them), which is not
> the case here.
> 
> Also be careful and pay attention to the end of the header; you do
> not want to pick up a random "parent" string in the middle of a log
> message.
> 
>     head2_parent=$(git cat-file commit HEAD | sed -n -e
> "s/^parent //p" -e "/^$/q")
> 
> would be much better.
> 
> > +	head2_parent_7=$(echo $head2_parent | cut -c1-7) &&
> > +	tree2=$(git cat-file -p HEAD | grep tree | cut -f 2 -d" ")
> > &&
> 
> Likewise.
> 
> > +	tree2_7=$(echo $tree2 | cut -c1-7)
> 
> Likewise.