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

Patrick Steinhardt [off-list ref] 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 <redacted>
---
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.