Why doesn't `git update-ref -d` delete empty parent directories?

Question

There are various types of refs in git, some of the most common of which are branches (stored in .git/refs/heads), remote-tracking branches (.git/refs/remotes), and tags (.git/refs/tags).

But it's also possible to create and use arbitrary non-standard refs that live elsewhere under .git/refs. This can be useful for storing custom metadata in the repository that you don't expect users will want to interact with directly. For example, GitHub uses these kinds of refs to expose references to pull request branches, and the Emacs git client Magit uses them to save uncommitted changes periodically, when the appropriate setting is enabled. Such refs would generally need to be manipulated using the so-called "plumbing" commands of git, since the user-facing "porcelain" commands don't know about or support them.

I was playing around with non-standard refs using the plumbing command git update-ref and found some odd behavior:

$ git init foo && cd foo
$ touch a && git add a && git commit -m init
$ tree .git/refs
.git/refs
├── heads
│   └── master
└── tags

2 directories, 1 file
$ git update-ref refs/foo/bar/baz HEAD
$ tree .git/refs
.git/refs
├── foo
│   └── bar
│       └── baz
├── heads
│   └── master
└── tags

4 directories, 2 files
$ git update-ref -d refs/foo/bar/baz
$ tree .git/refs
.git/refs
├── foo
├── heads
│   └── master
└── tags

3 directories, 1 file

When I created the ref refs/foo/bar/baz, git update-ref created the necessary parent directories. When I deleted the ref, it was smart enough to remove the parent directory bar, which had now become empty. However, it wasn't smart enough to remove the "grandparent" directory foo, which was also now empty after removing bar.

Is this a bug?

Note that there are more than just these two types of refs built in: there are also remote-tracking names (`refs/remotes//`), notes refs, bisect temporary refs, `refs/stash`, and so on. Branches and tags are just the most user-visible ones. — torek, May 20 '21 at 02:43
Thanks for pointing that out. I edited the post - let me know if it still seems inaccurate :) — kini, May 20 '21 at 06:07

score 2 · Accepted Answer · answered May 19 '21 at 13:49

No, it's by design. Here is a comment from the source code:

/*
 * Remove empty parent directories associated with the specified
 * reference and/or its reflog, but spare [logs/]refs/ and immediate
 * subdirs. flags is a combination of REMOVE_EMPTY_PARENTS_REF and/or
 * REMOVE_EMPTY_PARENTS_REFLOG.
 */
static void try_remove_empty_parents(struct files_ref_store *refs,
                     const char *refname,
                     unsigned int flags)
{

If I'd have nested my non-standard ref one level deeper, e.g. refs/foo/bar/baz/xyzzy, I'd have noticed that both the parent and grandparent directories were removed, but the great-grandparent wasn't, making it more obvious that this behavior is intentional.

I guess the idea is that the top level subdirectories under .git/refs/ (like foo in my example) represent a type of ref rather than being part of the name of the ref, so treating them differently from directories further down the tree (like bar in my example) makes sense.

As my comment under the question should imply, this is true, but also kind of suspect: `refs/stash` for instance does not have another level, while `refs/remotes` has *two* levels (the remote, then the name). Added work-trees get work-tree-specific refs as well, which complicate the picture more. The Git folks made a general mechanism, but then kind of made a mess with it. :-) — torek, May 20 '21 at 02:45

VonC · Answer 2 · 2021-06-13T14:08:09.287

This is formally addressed (for refs/heads only) with Git 2.32 (Q2 2021): when "git update-ref -d"^(man) removes a ref that is packed, it left empty directories under $GIT_DIR/refs/.

See commit 5f03e51 (08 May 2021) by Will Chandler (wlvchandler).
^{(Merged by Junio C Hamano -- gitster -- in commit 16f9145, 16 May 2021)}

refs: cleanup directories when deleting packed ref

^{Signed-off-by: Will Chandler}
^{Reviewed-by: Jeff King}

When deleting a packed ref via 'update-ref -d', a lockfile is made in the directory that would contain the loose copy of that ref, creating any directories in the ref's path that do not exist.
When the transaction completes, the lockfile is deleted, but any empty parent directories made when creating the lockfile are left in place.
These empty directories are not removed by 'pack-refs' or other housekeeping tasks and will accumulate over time.

When deleting a loose ref, we remove all empty parent directories at the end of the transaction.

This commit applies the parent directory cleanup logic used when deleting loose refs to packed refs as well.

The test shows:

directory not created deleting packed ref':

git branch d1/d2/r1 HEAD &&
git pack-refs --all &&
test_path_is_missing .git/refs/heads/d1/d2 &&
git update-ref -d refs/heads/d1/d2/r1 &&
test_path_is_missing .git/refs/heads/d1/d2 &&
test_path_is_missing .git/refs/heads/d1  <==== grand-parent is gone

However, this would not apply to refs/foo, as in the OP: git update-ref -d refs/foo/bar/baz does remove bar/baz, but not foo/.

Unless I'm missing something, this doesn't seem relevant since 1) it's about packed refs, and 2) it doesn't change the behavior I describe (leaving empty directories that are direct children of `refs/`). — kini, May 24 '21 at 07:50
@kini The test shows ot does remove empty directories in refs/heads. I'll have to test it in your case (un-packed refs) — VonC, May 24 '21 at 07:55
This question is specifically about refs that are not in refs/heads, i.e. non-standard custom refs (e.g. in refs/foo). — kini, May 24 '21 at 17:02

Why doesn't `git update-ref -d` delete empty parent directories?

2 Answers2

`refs`: cleanup directories when deleting packed ref

Why doesn't `git update-ref -d` delete empty parent directories?

2 Answers2

refs: cleanup directories when deleting packed ref

`refs`: cleanup directories when deleting packed ref