Git是否永远不会删除任何信息？ [英] Does Git never delete any information?

问题描述

我读过这篇文章：
http://jenkins-ci.org/content/summary-report-git-repository-disruption-incident-nov-10th

其中描述一个用户意外地从存储库的过期状态触发 git push --force 的事件。

现在当然这需要一些清理来恢复原来的状态分支。但是由于Git从不删除信息，因为我知道这个清理过程总是有可能的。

所以即使你重新绑定，推动力（和其他可能会重写历史）原始提交仍然存在，他们只需要找到正确的？

简而言之，git中的任何（破坏性）操作实际上会删除数据吗？

解决方案

通过任何引用无法访问的提交最终将被删除，其中包括reflog。这种情况的默认时间段非常保守。有几个选项可以用来通过 git config

很多人（包括我在内）都会建议您设置您的接收挂钩来拒绝非快速 - 前进合并，这在很大程度上使这个问题没有实际意义（在服务器上，个人可能仍然失去本地工作）。

  gc.auto 
当存储库中的这些松散对象大约多于此数时，git gc --auto将它们打包。一些Porcelain命令使用此命令不时执行轻量级垃圾回收。默认值为6700.将其设置为0将禁用它。 
 gc.pruneexpire 
当git gc运行时，它会调用prune --expire 2.weeks.ago。用此配置变量覆盖宽限期。值now可用于禁用此宽限期，并且总是立即修剪不可访问的对象。 
 
 gc.reflogexpire 
 gc。< pattern> .reflogexpire 
 git reflog expire删除比此时更早的reflog条目;默认为90天。使用< pattern> （例如refs / stash），该设置仅适用于与< pattern>匹配的参考。 
 
 gc.reflogexpireunreachable 
 gc。< ref> .reflogexpireunreachable 
 git reflog expire删除比此时更早的reflog条目，并且无法从当前提示中获取;默认为30天。使用< pattern> （例如refs / stash），则该设置仅适用于与< pattern>匹配的参考。 
  

I have read this post: http://jenkins-ci.org/content/summary-report-git-repository-disruption-incident-nov-10th

which describes an incident where a user accidentally triggered a git push --force from an outdated state of the repository.

Now of course this requires some clean up to restore the original state branches. But since Git never deletes information as I understand this clean up process is always possible.

So even though you rebase, push --force (and other operations that might rewrite the history) the original commits are still there they just needs to be found right?

In short are the any (destructive) operation in git that actually deletes data?

解决方案

Commits that are not reachable via any reference will eventually be deleted, which includes the reflog. The default time period for this to happen is pretty conservative. There are several options you can use to adjust this via git config See below for some of the specific options.

A lot of people (myself included), would suggest that you setup your receive hooks to deny non-fast-forward merges, which would largely make this issue moot (on the server, individuals could still lose unpushed local work).

gc.auto
When there are approximately more than this many loose objects in the repository, git gc --auto will pack them. Some Porcelain commands use this command to perform a light-weight garbage collection from time to time. The default value is 6700. Setting this to 0 disables it.
gc.pruneexpire
When git gc is run, it will call prune --expire 2.weeks.ago. Override the grace period with this config variable. The value "now" may be used to disable this grace period and always prune unreachable objects immediately.

gc.reflogexpire
gc.<pattern>.reflogexpire
git reflog expire removes reflog entries older than this time; defaults to 90 days. With "<pattern>" (e.g. "refs/stash") in the middle the setting applies only to the refs that match the <pattern>.

gc.reflogexpireunreachable
gc.<ref>.reflogexpireunreachable
git reflog expire removes reflog entries older than this time and are not reachable from the current tip; defaults to 30 days. With "<pattern>" (e.g. "refs/stash") in the middle, the setting applies only to the refs that match the <pattern>.

这篇关于Git是否永远不会删除任何信息？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！