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? Not really a topic for this series, but something to make a mental note of for the reftable topic, i.e. we may eventually want to edit the docs etc. appropriately if and when the new backend is more mature.
