From: Junio C Hamano <gitster@pobox•com>
To: Patrick Steinhardt <ps@pks•im>
Cc: git@vger•kernel.org
Subject: Re: [PATCH] refs/files: remove empty parent dirs when ref creation fails
Date: Tue, 08 Jul 2025 14:52:21 -0700 [thread overview]
Message-ID: <xmqqzfdes63u.fsf@gitster.g> (raw)
In-Reply-To: <20250708-b4-pks-reffiles-prune-empty-dirs-on-abort-v1-1-3bae02e4f034@pks.im> (Patrick Steinhardt's message of "Tue, 08 Jul 2025 12:19:54 +0200")
Patrick Steinhardt <ps@pks•im> 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 <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.
prev parent reply other threads:[~2025-07-08 21:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-08 10:19 [PATCH] refs/files: remove empty parent dirs when ref creation fails Patrick Steinhardt
2025-07-08 21:52 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqzfdes63u.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox