Subject: Re: [PATCH 1/2] update-ref: Allow creation of multiple transactions

From: Junio C Hamano <[email-masked]>
Date: Thu, 05 Nov 2020 13:34:20 -0800

Jeff King <[email-masked]> 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.