Re: [PATCH] refs/files: remove empty parent dirs when ref creation fails
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 8, 2025, 21:52 UTC
- Message-ID
- <xmqqzfdes63u.fsf@gitster.g>
- In-Reply-To
- <20250708-b4-pks-reffiles-prune-empty-dirs-on-abort-v1-1-3bae02e4f034@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
Show 23 quoted lines
> When creating a new reference in the "files" backend we first create the > directory hierarchy for that reference, then create the lockfile for > that reference, and finally rename the lockfile into place. When the > transaction gets aborted we prune the lockfile, but we don't clean up > the directory hierarchy that we may have created for the lockfile. > > In some egde cases this can lead to lots of empty directories being > cluttered in the ".git/refs" directory that really serve no purpose at > all. We know to prune such empty directories when packing refs, but that > only patches over the issue. > > Improve this by removing empty parents when cleaning up still-locked > references in `files_transaction_cleanup()`. This function is also > called when preparing or committing the transaction, so this change also > helps when not explicitly aborting the transaction. > > Signed-off-by: Patrick Steinhardt <ps@pks.im> > --- > Hi, > > this issue is something we recently discovered in Gitaly. It's nothing > world breaking, but I think it makes sense to try and keep the refdb in > a as-clean-as-possible state anyway.
Would we lose an empty ".git/refs/tags/" directory if we fail to create the first tag?
... goes and looks at the try_remove function ...
OK, we protect the leading two levels when doing so, so we are safe.
Will queue. Thanks.