Re: [PATCH 1/2] update-ref: Allow creation of multiple transactions
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 5, 2020, 21:34 UTC
- Message-ID
- <xmqqa6vvij37.fsf@gitster.c.googlers.com>
- In-Reply-To
- <20201105192901.GA121650@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 18 quoted lines
>> +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-branchcannot 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.