Subject: Re: [PATCH] refs/files: remove empty parent dirs when ref creation fails

From: Junio C Hamano <[email-masked]>
Date: Tue, 08 Jul 2025 14:52:21 -0700

Patrick Steinhardt <[email-masked]> writes:

> 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 <[email-masked]>
> ---
> 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.