【问题标题】:Git distribute fixup commit to original commitsGit 将修复提交分发到原始提交
【发布时间】:2014-10-07 21:45:46
【问题描述】:

有以下琐碎的提交

# define function in one file
echo "function foo () {}" > a
git add a
git commit -m "1st commit"

# call the function in different file
echo "foo()" > b
git add b
git commit -m "2nd commit"

# rename foo to bar in both files
echo "function bar () {}" > a
echo "bar()" > b
git commit -am "fixup"

是否可以自动拆分修复提交以更新之前的两个提交?

我在想,如果修复提交仅更改原始提交中更改的行,则确实应该可以通过算法精确地拆分修复提交。是这样吗?如果支持,git 支持吗?

我知道这可以通过多个变基和手动拆分修复提交来完成,但这不是我想要的。

澄清:想象一下在功能分支上工作。你有很多提交。经过代码审查,发现例如方法foo 应该命名为方法bar。现在在推送到上游之前,我宁愿不只是更改它的所有实例添加一个新的提交,而是拆分最后一个提交并将其部分应用于适当的先前提交。

【问题讨论】:

  • 为什么不使用git mv 重命名一个文件并提交,然后git mv 重命名另一个文件并提交?
  • 我不是在重命名文件,而是在重命名一个函数,这只是一个简化示例(可能是任意文本)。

标签: git


【解决方案1】:

如果我将您的问题解释为“我如何在它出现的所有提交中重命名一个函数”,那么以下工作(针对您提供的两个示例提交进行了测试,但不打算完全发挥作用)。

在处理功能分支时,您需要将其传入以限制 filter-branch 尝试处理的提交数量。

git filter-branch --tree-filter 'git grep --name-only foo | xargs sed -i "s/foo/bar/g"'

【讨论】:

  • 谢谢,这实际上适用于这个简化的例子,但想象一下现实世界的例子:有一个可能比 sed 改变更多的修正提交。我似乎无法正确表达这个问题(这是这里最大的问题)。
  • 我只能推测,没有具体细节。一般来说,我不会说(如果你不能描述应该如何拆分补丁以及应该如何应用它,那么就没有办法对其进行编程),尽管你可以通过使用 git commit --fixuprebase.autosquash true 来简化很多事情
  • 对,我想我得想出一个反例,它不能自动证明自己错了。
猜你喜欢
  • 2011-07-18
  • 1970-01-01
  • 2021-03-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-12-04
  • 2014-05-24
相关资源
最近更新 更多