显然与人类(能够理解代码的人)无关的更改经常被Git的diff算法搞砸。例如
def method_that_already_existed(blah)
a line that did not change
a line that was deleted ######## the changed area starts here (per Git)
a new line
end
def a newly_added_method_that_belongs_in_its_own_commit
blah blah blah
blah blah blah
etc. ######## the changed area ends here (per Git)
end
对人类来说,第一种方法和全新方法的变化是完全不同的。但是Git将它们视为一体,并且不允许我在任何情况下拆分它们。
如果我使用
git add -p ./path/to/file
s
e
用于编辑,但不允许添加最终
end
第二种方法。所以基本上Git完全没有办法智能地选择更改并在单独的提交中分别添加它们。
所以我找不到办法控制这个,
除非我改变密码
只是为了骗吉特做正确的事
. 如果我深入到历史中获取第一个方法中删除的行并将其添加回,然后删除(临时)添加的行并保存文件,那么它将正确识别已更改的内容。当然,我必须记住撤销这个笨拙的解决方案,并确保我撤销它正确,否则我已经破坏了我的代码。这是一个乏味而可怕的解决方法。
如果有一种方法能让Git像人类那样“正确地”识别变化,我会很高兴的。在我们有了基于AST的diff算法之前,我不希望这个能很快出现。所以下一个最好的办法就是
例如(这只是部分解决问题的一种方法),如果我能告诉Git永远不要让diff块跨越空行,我会解决这个特殊的例子。如果我有一个块要跨越一个空行,我很乐意分别添加这两个块。Git应该
总是
基本问题是:
如果Git不能正确地识别发生了什么变化,我如何强迫它接受我的版本(不必求助于繁琐的;容易出错的乱七八糟的事情,比如通过挖掘git历史来手动撤消某些更改,从而撤消其中一个更改,这样就不会错误地将两个单独的事情组合在一起!)
