git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Keep reflogs for deleted (remote tracking) branches?

From
Tao Klerks <tao@klerks.biz>
Date
Mar 8, 2022, 11:27 UTC
Message-ID
<CAPMMpog=qBwLrxss_ci6ZMM+AjbdrF8tszXLW7YH1Zqr+m7mPQ@mail.gmail.com>
Hi folks,
I have a practical question in case I missed something.

Imagine a small team (10ppl) working on a single centralized repo, in github for example. They regularly create new branches, and typically delete them eventually - after merging, or at other times when branches were a dead end or whatever. The members of this team all have a "simple" git remote configuration, the result of a "git clone" with no special configuration. One exception is that they have set "fetch.prune" to "true", because otherwise remote branches that have been deleted (in the context of completed merges, or arbitrarily by other team members) accumulate locally and having to explicitly prune them from time to time is a pain. Every time someone says "why do I still see these branches in my repo?", someone else replies "oh, just run 'git config fetch.prune true'".

Now, one day someone deletes a branch accidentally from the server, and the sole author of that branch has gone on vacation (or has an IT failure, or has left the company, or whatever). Other team members have seen this branch go by, it's appeared in their "fetch" output, but no-one remembers checking it out, so it's not in their main "HEAD" reflogs.

Even though the ref was at one point on every team member's computer, and they still undoubtedly have a dangling commit in their repos, they're going to have a hard time finding it - there are many dangling commits in any given repo.

Now my question: is there any way to (temporarily) keep a reflog for that deleted/pruned branch, in those team members' repos?

As far as I can tell, even "core.logAllRefUpdates=always" does *not* keep any reflog entries around, even temporarily (until reflog expiry), once a ref is deleted - do I understand that correctly? Is this behavior intentional / reasoned, or just a consequence of the fact that it's *hard* to keep "managing" per-branch reflogs for branches that don't exist?

I am planning a workaround using server hooks to "back up" refs that are being deleted from specific namespaces, in my specific case, and I imagine that a system like github keeps track of deleted stuff itself for a while, but I find this "per-ref reflog disappearance" behavior puzzling / out-of-character, so wanted to make sure I'm not missing something.

Thanks, Tao

Next: Han-Wen Nienhuys
Message 1 of 8 in “Keep reflogs for deleted (remote tracking) branches?”
  1. Tao KlerksMar 8, 2022
  2. Han-Wen NienhuysMar 8, 2022
  3. Ævar Arnfjörð BjarmasonMar 8, 2022
  4. Tao KlerksMar 14, 2022
  5. Ævar Arnfjörð BjarmasonMar 14, 2022
  6. Tao KlerksMar 14, 2022
  7. Jeff HostetlerMar 8, 2022
  8. Tao KlerksMar 14, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.