On Sun, Jul 30, 2017 at 02:21:50PM -0700, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > One approach I had considered taking is having a helper of some sort
> > that wrapped a simple key/value store.  We could pass the wrapper the
> > SHA-1 value (or, if necessary, an arbitrary key) and have it return the
> > proper value based on the given hash function.
> >
> > That does have the downsides that the values may not present in the
> > tests themselves, and that people adding new tests will of course need
> > to run the test suite twice.  But it does make the tests easier to read.
> >
> > Opinions on the desirability of this approach are of course welcome.
> 
> I am not quite sure if I follow.  There was a proposal to tweak the
> commit format that uses the new hash in such a way that we can tell
> what SHA-1 would have been used if everything were SHA-1 (I think it
> was from Jonathan, but I may be mistaken), and I recall that
> generally the list were receptive to the idea.  But I have a feeling
> that your "helper of some sort" is something else.
> 
> If your <key,value> is about letting us store something like
> 
>  - If you hash "hello\n" the resulting blob in SHA-1 world has this
>    object name, and with that, you can find out the equivalent
>    object name in SHA-256 world.
> 
>  - If you have a tree with the above blob at path P and nothing
>    else, then the object name of that tree in the SHA-1 world and
>    SHA-256 world are different and we can map between them.
> 
>  - Likewise for a commit that points at the above tree with fixed
>    date, author and message.
> 
> I am not sure how much it would help.  Are you aiming to make it
> easier and more structured to create a patch like what Stefan did
> recently for t8008 in 0ba9c9a0 ("t8008: rely on rev-parse'd HEAD
> instead of sha1 value", 2017-07-26)?

Yes, basically, but a bit more generally.  There will always be cases in
which we need to specify an object ID or an arbitrary string and the
behavior will need to vary based on the hash.  That can be something
like, in this case, the two blob contents that would have the similar
prefix.

So in this case, we pass the helper the string "263 410" and get back a
value for either the hacked SHA-1 hash or the SHA-256 or whatever we're
using.

This was basically a nicer way of wrapping the case statement that you
had given as an example.  Of course, it doesn't relieve us of doing the
hard work of analyzing the tests, which Stefan is doing, and with which
I don't want to interfere.

It was simply a proposal for a future direction which we could take if
we found ourselves needing to write a large number of hash-specific case
statements.  I'm happy to wait to actually implement that code until we
decide we need such a thing.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204