2014-10-07 114 views
0

具有以下瑣碎的承諾Git的分配修正承諾原來承諾

# 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。現在,在推向上游之前,我寧願不只是更改它的所有實例,而是添加一個新的提交,但拆分最後一個提交併將其部分應用到適當的提交。

+0

爲什麼不使用'git mv'來重命名一個文件,然後提交,然後'git mv'重命名另一個,並提交? – VonC 2014-10-07 11:21:26

+0

我不重命名文件,我正在重命名一個函數,這只是一個簡單的例子(它可能是任意文本)。 – 2014-10-07 11:24:36

回答

1

如果我將您的問題解釋爲「我如何在所有提交中顯示的函數中重命名函數」,則以下工作(針對您提供的兩個示例提交進行測試,但不打算完全實用)。

在功能分支上工作時,您需要通過它來限制filter-branch嘗試處理的提交數量。

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

謝謝,這實際上適用於這個簡化的例子,但想象一下現實世界的例子:有一個修復提交可能會改變不止一個sed的意願。我無法正確表達這個問題(這是這裏最大的問題)。 – 2014-10-07 15:23:08

+0

我只能猜測沒有具體細節。一般來說,我不會說(如果你不能描述補丁應該如何拆分以及如何應用它,那麼就沒有辦法編程),儘管你可以通過使用'git commit --fixup'來簡化很多事情和'rebase.autosquash true' – 2014-10-07 15:27:27

+0

對,我想我會想出一個反例,它不能自動工作證明自己錯了。 – 2014-10-07 16:51:29