Am 26.08.21 um 01:28 schrieb Ævar Arnfjörð Bjarmason: > > On Wed, Aug 25 2021, Junio C Hamano wrote: > >> René Scharfe <l.s.r@xxxxxx> writes: >> >>> 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 <l.s.r@xxxxxx> >>> --- >>> Original submission: >>> http://public-inbox.org/git/52847a99-db7c-9634-b3b1-fd9b1342bc32@xxxxxx/ >> >> Thanks. >> >>> +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é
