Is there any reason to not set 'git fetch' to always use the --prune option?

Question

Using git fetch --prune deletes local remote tracking branches when the branch on the remote machine has been deleted. Setting remote.origin.prune to true using the following...

git config --global fetch.prune true

...makes using the fetch command always implicitly use the --prune option.

I am putting together a best-practices/introduction to git for some developers in my group who aren't quite familiar with it. I want to be sure I know this is not a dangerous behavior before advising them to do so. I at least give them a heads up of what to watch out for if there is some extraneous mishap case.

It doesn't seem like this is a destructive operation because it doesn't delete any local (non-remote) branches. It also seems like this is a great way to not build up remotes that aren't in use anymore without periodically specifying git fetch --prune or git remote prune.

If this is all true, why is this not the default behavior for git?

Answer 1

It's not fundamentally dangerous, and I have been tempted to set it in my own --global settings, but I never have: primarily because it also has relatively little value to me.¹

As you note, the intent is, in essence, to remove origin/zorg once branch zorg is no longer present on origin. Since this has no direct effect on your own zorg, if you have one at all, it's generally harmless, and declutters your view of remote-tracking branches. The only two possible downsides are:

1. If someone mistakenly deletes zorg on the upstream repository, and all the downstream copies prune their origin/zorg, you lose the ID of the commit (and perhaps many commits themselves) that was the tip of zorg in that upstream repository. So it magnifies the effect of some mistakes. (Of course, if the upstream repository is that important, you probably should be making backups anyway—though if you choose to use the clones as backups, automatic pruning has a downside there. Of course, you can always disable automatic pruning specifically on these backups.)

2. Suppose you do have your own zorg that is tracking origin/zorg, and the upstream zorg gets deleted (on purpose this time). Note that it has been your origin/zorg that provides you with git status information telling you how many commits you were ahead of origin/zorg. Suppose that you would now like to move these commits, but not commits-that-used-to-be-upstream, to another of your own branches. In this case, automatically pruning your own origin/zorg makes it difficult to tell which commits were yours, and which were already in the upstream.

Note that in case 2, you do not lose any commits. What you lose is the ability to tell that, e.g., only the last three commits currently on your zorg were your own, with several before that (that are not on any other branch now) having originally been on origin/zorg.

---

¹Over the years, the pruning code has sometimes been somewhat broken, mostly in terms of failing to prune. This implies that the Git developers themselves probably don't use it much (but things should be better now since there are now tests in Git's internal test-suite to make sure pruning works correctly in new releases). So between "low value" and "insufficient testing in the past", that was, at least at the time, sufficient reason not to set it.