Johannes Schindelin writes: > Hi Thomas, > > On Fri, 28 Jan 2022, Thomas Gummerer wrote: > >> Junio C Hamano writes: >> >> > Thomas Gummerer <t.gummerer@xxxxxxxxx> writes: >> > >> >> +test_expect_success REFFILES 'fetch --prune fails to delete branches' ' >> >> + cd "$D" && >> >> + git clone . prune-fail && >> >> + cd prune-fail && >> >> + git update-ref refs/remotes/origin/extrabranch main && >> >> + >.git/packed-refs.new && >> >> + test_must_fail git fetch --prune origin >> > >> > Is it because the lockfile ".new" on packed-refs prevents deletion >> > of refs but does not block creation and updates to existing refs >> > that it is an effective test for the "--prune" issue? If we somehow >> > "locked" the whole ref updates, then the fetch would fail even >> > without "--prune", so it may be "effective", but smells like knowing >> > too much implementation detail. Yuck, but I do not offhand think of >> > any better way (it is easier to think of worse ways), so without >> > further input, I would say that this is the best (or "least bad") we >> > can do. >> >> Yes, that's correct. New refs will be created as loose refs, so they >> don't care about packed-refs. However deletions can potentially be >> happening in packed-refs, and that's why it fails when 'packed-refs.new' >> exists. >> >> I don't love the test either, but I also can't think of a better way to >> do this. > > Maybe add a code comment about it? Something like: > > [...] > : this will prevent --prune from locking packed-refs && > >.git/packed-refs.new && > [...] Yeah, I think a comment here is a good idea, thanks!
