【问题标题】:Confused by git filter-branch被 git filter-branch 搞糊涂了
【发布时间】:2015-04-20 19:39:07
【问题描述】:

我需要分析在整个历史过程中给定目录中的某些文件到底发生了什么,使用 git log the_directory 之类的东西还不够好。所以我虽然我会创建一个只包含相关文件的分支。

我编写了一个 perl 脚本 remove-all-but-stuff 并验证它可以正常工作。最初,我认为只需删除文件即可,但后来我将其修复为使用

system qw(git rm -r --ignore-unmatch --quiet), @files

@files 包含在工作树中找到的不需要的目录和文件 - 这可能是个问题吗?

我创建了一个新分支并通过

过滤它
git filter-branch --tree-filter remove-all-but-stuff my-branch

最后文件消失了,但这发生在最后一次提交中。历史记录包含对不应存在的文件的更改。

我正在使用 git 版本 2.3.5。知道我做错了什么吗?


现在我什至添加了一些@files 的路径,而不查看是否存在。发生了一些变化(Ref 'refs/heads/my-branch' 已被重写),但不需要的文件(甚至在添加的路径下方)仍在历史记录中。

【问题讨论】:

  • 我只是把它留在这里: git gui blame somefile.txt 提供了一个显示文件和所有修改来源的 GUI。您可以通过单击与每一行相关的提交的哈希来浏览文件的历史记录。这是深入查看文件历史记录的最佳方式 (imo)。
  • @FélixCantournet 我的问题是一堆文件和其中的许多更改(只有两个重命名)。在命令行上指定它们是一件很痛苦的事情,因为文件名称中有空格和类似的罪行。过滤后的效果好多了。

标签: git git-filter-branch git-rewrite-history


【解决方案1】:

这是相当愚蠢的,但这是我这边的一个错误。1我忽略了一个(隐藏得很好的)错误消息。问题是

error: the following files have changes staged in the index:

(隐藏在一行的末尾,后面可能有数百个文件)。我想,我忘记了-f 修饰符(也忘记了因错误而退出)。

实际上,似乎没有理由同时使用git rm 而不是/bin/rm--tree-filter


1 我考虑过删除我的问题,但是,它可能会节省一些时间。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2013-12-31
    • 2014-08-14
    • 2015-12-28
    • 2017-01-16
    • 2022-01-23
    • 2019-01-12
    • 1970-01-01
    • 2016-02-16
    相关资源
    最近更新 更多