2014-09-19 75 views
6

我需要自動化交互式rebase或用其他命令替換它。讓我解釋我目前的情況:git:如何自動化交互式rebase /用等價的git命令替換它

在svn-> git轉換中,我需要重新綁定新創建的git存儲庫以修復SVN期間創建的「歷史截斷」。這是我的手動工作流程來解決問題。

branchNEW: containing history from SOMEDAY until now 
branchOLD: containing history from past to SOMEDAY 

編輯或ASCII:

branchNEW:  Y - Z 
branchOLD: W - X 

兩個分支沒有共同提交。

現在的基本想法是將branchNEW重新綁定到branchOLD上。不幸的是,有一些重構SOMEDAY:有些文件被移動到另一個目錄。現在,重定位的結果是,每個移動的文件都存在於兩個地方。

編輯

some file exist in X 
the (nearly) same files also exist in Y, just on another path 

branchNEW: W - X - Y - Z 
(after rebase) 

底墊後,HEAD現在包含X的文件和Y的我也嘗試添加了新的承諾branchOLD其刪除舊文件。在底座SVN-HEAD和git-HEAD二進制相同之後,但「git log --follow」不起作用。

我們的主要問題:我能夠通過使用第二,互動變基到解決這個問題:

git rebase -i SHA 

SHA是根的SHA-ID犯branchNEW。現在在編輯器中,我必須將「pick」更改爲「編輯」最頂層的提交。退出編輯器後,我現在刪除了錯誤的文件

git rm -f fileA fileB 
git commit --amend 
git rebase --continue 

這個混帳頭後是二進制等同於SVN的,另外頭,Git有完整的歷史,也有「git的日誌--follow」工程爲移動的文件。

由於這一步只是未來巨大的VCS轉換的一小部分,我需要編寫完整的流程腳本。 但如何自動執行上述步驟?

(我知道的SHA不會保持不變,但我能夠得到從SVN-ID被嵌入在每一個提交信息所需SHA)

+0

我不確定,但'git filter-branch'可以幫助你。 – Jubobs 2014-09-19 16:58:51

回答

3

我發現了一個可能的解決方案:

git rebase --interactive將「rebase commitits列表」(您可以選擇,存儲,編輯的列表)發送給編輯器。可以配置哪種編輯器。所以解決方案是爲這個交互式底座配置一個替代的「編輯器」。

GIT_SEQUENCE_EDITOR="command" git rebase -i SHA 

命令可能是一個shell腳本,或只是一個簡單的sed:這可以通過使用環境變量GIT_SEQUENCE_EDITOR做

GIT_SEQUENCE_EDITOR="sed -i 's/^pick ce5efdb /edit ce5efdb /;/^pick ce6efdb /d'" git rebase -i SHA 

重要:「底墊的名單提交」作爲傳遞文件到命令。所以命令必須接受一個文件名作爲參數,並且必須將結果寫入相同的文件。 「sed -i」正在這樣做。

+0

我需要在倉庫中自動壓縮一些歷史提交,以便創建一個腳本來執行從svn遷移所需的所有操作,作爲其他項目成員可以以完全可重複的方式使用的概念驗證驗證遷移是否正確。這是完美的。 – Irfy 2016-05-19 08:09:46

0

expect也可能幫助你。雖然這不是你需要做的,但你應該能夠使用類似的東西來自動化你的過程:

#!/usr/bin/env expect 
spawn git rebase -i HEAD~2 

# down, delete word, insert 's' (for squash), Escape, save and quit 
send "jdwis \033:wq\r" 

expect "# This is a" 

# down 4, delete 3 lines, save and quit 
send "4j3d:wq\r" 

interact 
相關問題