Re: [PATCH RESEND] branch: allow deleting dangling branches with --force

Am 26.08.21 um 01:28 schrieb Ævar Arnfjörð Bjarmason:

On Wed, Aug 25 2021, Junio C Hamano wrote:

quoted

René Scharfe [off-list ref] writes:

quoted

git branch only allows deleting branches that point to valid commits.
Skip that check if --force is given, as the caller is indicating with
it that they know what they are doing and accept the consequences.
This allows deleting dangling branches, which previously had to be
reset to a valid start-point using --force first.

Signed-off-by: René Scharfe <redacted>
---
Original submission:
http://public-inbox.org/git/52847a99-db7c-9634-b3b1-fd9b1342bc32@web.de/

Thanks.

quoted

+test_expect_success 'branch --delete --force removes dangling branch' '
+	test_when_finished "rm -f .git/refs/heads/dangling" &&
+	echo $ZERO_OID >.git/refs/heads/dangling &&
+	git branch --delete --force dangling &&
+	test_path_is_missing .git/refs/heads/dangling
+'

This goes against the spirit of the series merged at c9780bb2 (Merge
branch 'hn/prep-tests-for-reftable', 2021-07-13).

Can we creat the dangling ref and test the lack of "dangling" ref in
the end in a less transparent way?

An escape hatch is to make this test depend on the REFFILES
prerequisite, just like dc474899 (t4202: mark bogus head hash test
with REFFILES, 2021-05-31) did, which may be more appropriate.

I'm not sure, but this may also be a good example of the sort of thing
that we should probably go beyond REFFILES with, i.e. is it even
possible under reftable to run into this sort of situation?

Probably yes: A commit can disappear when its object file or pack or
alternate object database gets lost somehow, and a ref store could
only compensate for that loss if it kept a copy of the ref target,
which seems impractical.

René