Jeff King <peff@xxxxxxxx> writes:
>> +test_expect_success 'transaction can create and delete' '
>> + cat >stdin <<-EOF &&
>> + start
>> + create refs/heads/create-and-delete $A
>> + commit
>> + start
>> + delete refs/heads/create-and-delete $A
>> + commit
>> + EOF
>> + git update-ref --stdin <stdin >actual &&
>> + printf "%s: ok\n" start commit start commit >expect &&
>> + test_path_is_missing .git/refs/heads/create-and-delete
>> +'
>
> The tests all look quite reasonable to me. Touching .git/refs like this
> is a bit gross (and something we may have to deal with if we introduce
> reftables, etc). But it's pretty pervasive in this file, so matching
> the existing style is the best option for now.
Shouldn't "git show-ref --verify" be usable portably across ref backends
to test if a well-formed ref was created (or was not created)?
On the ref-creation side, there are cases where we need to directly
futz with the filesystem entity. For example, "git update-ref"
cannot be used to place a non-commit at "refs/heads/foo", so
something like
git rev-parse HEAD^{tree} >.git/refs/heads/bad-branch
cannot be avoided (this is a tangent but we probably should add a
way to force setting _any_ value to any ref, that may not even point
at an existing object or an object of a wrong type, to help test
scripts).
But I do not think this is such a case.
