2014-09-19 45 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 
相关问题