Re: [PATCH v2 01/11] t: add tool to translate hash-related values

> On Sun, Aug 19, 2018 at 5:50 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> > I think what I'd like to do instead is store in a variable and make
> > test_oid return unsuccessfully if the value doesn't exist.  I think
> > that's better for writing tests overall and will accomplish the same
> > goal.
> 
> My knee-jerk reaction is that could get clunky in practice, but
> perhaps I'm not seeing the full picture.
> 
> An alternative would be to return a distinguished error value.

> > Putting them in a separate directory makes it possible to do something
> > like this:
> >
> >    (cd t && ./t0002-* --verbose)
> >
> > and then use shell editing to change the command line.  If we put them
> > in the same directory as the tests, we make developers' lives a bit
> > harder.
> 
> Perhaps I'm missing something obvious, but I'm not following what
> you're trying to convey.
> 
> Okay, thinking upon this further, I guess you mean people who type
> your example directly rather than using "./t0002-*.sh" or something.

> I'm still open to the idea of supporting experimentation with other
> hash algorithms and I see how lumping all the OID tables into a single
> directory can make it easy to locate everything that will require
> adjustment for a new algorithm. But, this information can also be
> gleaned via a simple grep for "test_oid_cache", so I'm not sure the
> lumped-directory approach buys much.
> 
> Also, my gut feeling is that such experimentation will be very rare,
> whereas the addition of new tests which have some sort of
> OID-dependency will likely be a more frequent occurrence. And, the
> locality of an OID-table plopped down right next to the test which
> requires it seems a win (in my mind).

> However, I'm sympathetic to the ugliness each caller having to specify
> "$TEST_DIRECTORY/...". In my review of 2/11, I suggested the idea of a
> test_oid_init() function which could load those common OID tables for
> scripts which need them, thus hiding that ugliness. Another idea which
> has some appeal is to define an $OIDDB variable (or some such name)
> with value "$TEST_DIRECTORY/oid-info", which lets callers use:
> 
>     test_oid_cache <"$OIDDB/bloop"
> 
> which isn't so bad.