有什么理由不将'git fetch'设置为始终使用--prune选项吗? [英] Is there any reason to not set 'git fetch' to always use the --prune option?

问题描述

使用git fetch --prune删除远程计算机上的分支后，将删除本地远程跟踪分支.使用以下命令将remote.origin.prune设置为true ...

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

...使用fetch命令制作的内容总是隐式使用--prune选项.

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

我正在为不熟悉它的小组中的一些开发人员提供git的最佳实践/介绍.我想确保我知道这不是危险的行为，然后建议他们这样做.如果发生一些无关的事故，我至少要提醒他们要注意的事项.

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.

这似乎不是破坏性操作，因为它不会删除任何本地(非远程)分支.似乎这也是不定期不使用git fetch --prune或git remote prune而不建立不再使用的远程站点的好方法.

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.

如果这都是真的，为什么这不是git的默认行为?

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

推荐答案

从根本上讲它并不危险，我很想在自己的--global设置中进行设置，但我从来没有这样做:主要是因为它也相对较少给我的价值. ¹

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.¹

正如您所指出的，本质上是要在origin上不再存在分支zorg时删除origin/zorg.因为这对您自己的zorg没有直接影响，所以如果您只有一个，它通常是无害的，并且会使您对远程跟踪分支的看法变得混乱.仅有的两个缺点是:

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. 如果某人错误地删除了上游存储库中的zorg，并且所有下游副本都修剪了它们的origin/zorg，您将丢失提交的ID(也许很多提交本身)这是该上游存储库中zorg的提示.因此，它会放大某些错误的影响. (当然，如果上游存储库非常重要，则无论如何您都应该进行备份－尽管如果选择使用克隆作为备份，则自动修剪有一个缺点.当然，您始终可以专门针对这些副本禁用自动修剪备份.)

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.)

假设您 do 拥有自己的正在跟踪origin/zorg的zorg，并且上游zorg被删除(这次是有意的).请注意，正是您的origin/zorg为您提供了git status信息，告诉您在origin/zorg之前的提交次数.假设您现在想移动这些提交，但不希望将用于上游的提交提交到您自己的另一个分支中.在这种情况下，自动修剪您自己的origin/zorg使得很难分辨出哪些是您的提交，哪些已经在上游.

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.

请注意，在情况2中，您不会丢失任何提交.您失去的是能够告诉您的能力，例如，您当前仅在您的zorg上的最后三个提交是您自己的，而之前的几个(现在不在任何其他分支上)具有最初的提交在origin/zorg上.

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.

¹ 多年来，修剪代码有时会被破坏，主要是因为无法修剪.这意味着Git开发人员本身可能并没有太多使用它(但是现在情况应该会更好，因为Git内部测试套件中现在有测试可以确保修剪在新版本中可以正常工作).因此，在低价值"和过去的测试不足"之间，至少在当时，这是没有设置它的充分理由.

¹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.

这篇关于有什么理由不将'git fetch'设置为始终使用--prune选项吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！