blocks|key|1985787|text|从新存储库中，添加对旧存储库的远程引用：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1985788|git+remote+add+temp+file:///path/to/old/repo/on/your/machine|code-block|syntax|javascript|1985789|从旧的存储库获取：|1985790|git+fetch+temp|1985791|查看旧存储库中的主分支：|1985792|git+checkout+temp/master+-b+wip|1985793|(wip代表正在进行的工作)|1985794|在当前存储库中的内容之上重新设置更改的基础：|1985795|git+rebase+master|1985796|将master更新为指向您的新头部：|1985797|git+checkout+master
git+merge+wip|1985798|删除对旧存储库和您使用的wip分支的远程引用：|1985799|git+branch+-d+wip
git+remote+rm+temp|1985800|您实际在做的事情：|1985801|首先，通过添加远程引用和获取，您可以从以前的存储库中提取当前存储库中还没有的提交。Git知道如何做到这一点，因为，无论它在哪里或如何进行，相同的提交在任何地方看起来都是一样的。它是一些众所周知的信息的SHA1散列，包括目录树、提交者、时间戳等。|1985802|因此，当您基于相同的SVN存储库创建一个新的Git存储库时，所有提交都具有相同的SHA1和。因此，您获取到当前存储库中的新提交继续指向正确的内容。这很酷，记住这一点很重要。|1985803|然后切换到temp的master分支的顶端，并告诉它重新建立到您当前的master上。rebase可能是不必要的，因为来自SVN的master可能没有从旧repo中的master移走，但最好是安全的。|1985804|rebase通过回溯两个提交的历史，直到它们都指向同一个父提交，从而找到两个提交之间最近的共同点。然后，它切换到您为其指定的分支名称(在本例中为master)，并从原始分支的历史记录中挑选缺失的每个提交。一旦完成，它将指向您在上次应用提交时所在的分支。|offset|length|style|CODE|1985805|最后，master和wip的合并只是为了将master快进到底。因为它是一条直线，所以它真的只是一个快进。您可以很容易地完成rebase或reset+--hard；任何这些操作都会改变主分支，使其指向正确的位置。Merge是其中最安全的，因为如果发生了一些奇怪的事情，它会让你知道这不是一个简单的快进。|1985806|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|20|6|0|0^^$0|@$1|2|3|4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1M|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|1N|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|1O|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1P|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1R|8|@]|9|@]|A|$]]|$1|S|3|T|5|D|7|1S|8|@]|9|@]|A|$E|F]]|$1|U|3|V|5|6|7|1T|8|@]|9|@]|A|$]]|$1|W|3|X|5|D|7|1U|8|@]|9|@]|A|$E|F]]|$1|Y|3|Z|5|6|7|1V|8|@]|9|@]|A|$]]|$1|10|3|11|5|D|7|1W|8|@]|9|@]|A|$E|F]]|$1|12|3|13|5|6|7|1X|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|20|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|21|8|@$1C|22|1D|23|1E|1F]]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|24|8|@]|9|@]|A|$]]|$1|1I|3|-4|5|6|7|25|8|@]|9|@]|A|$]]]|1J|$]]

From your new repository, add a remote reference to your old repository:

<pre><code>git remote add temp file:///path/to/old/repo/on/your/machine
</code></pre>

Fetch from the old repo:

<pre><code>git fetch temp
</code></pre>

Check out your master branch from the old repo:

<pre><code>git checkout temp/master -b wip
</code></pre>

(wip stands for work-in-progress)

Rebase the changes on top of the stuff in your present repository:

<pre><code>git rebase master
</code></pre>

Update master to point at your new HEAD:

<pre><code>git checkout master
git merge wip
</code></pre>

Delete the remote reference to your old repo and the wip branch that you used:

<pre><code>git branch -d wip
git remote rm temp
</code></pre>

What you are actually doing:

Firstly, by adding the remote reference and fetching, you are pulling the commits from your previous repository which you do not yet have in your current repository. Git knows how to do this because, no matter where or how it was made, the same commit looks the same everywhere. It is the SHA1 hash of a few well-known pieces of information, including the directory tree, the committer, timestamp, ...

So when you created a new Git repository based on the same SVN repository, all the commits had the same SHA1 sums. As a result, the new commits that you fetched into your current repository continued to point at the right stuff. This is very cool, and important to remember.

You then switched to the tip of temp's master branch and told it to rebase onto your current master. The rebase may have been unnecessary, as master from SVN may not have moved away from the master in your old repo, but it was best to be safe.

A rebase finds the nearest point of commonality between two commits by working backwards through their histories until they both point at the same parent commit. It then switches to the branch name you gave it (in this case <code>master</code>) and cherry-picks each of the commits that were missing from its history from your original branch. Once complete, it points the branch you were on when you started at the last commit it applied.

Finally, the merge of master with wip was just to fast-forward master to the end. As it was a straight line, it really was just a fast-forward. You could have just as easily done a rebase or a reset --hard; any of these would have altered the master branch to point at the correct location. Merge was just the safest of these, because if something weird had happened, it would have let you know that it was not a simple fast-forward.

I've been using git-svn, and recently, I've been getting errors when trying to commit (I think this is due to a bug in libneon, but this is beyond the scope of this question). The solution has been to re-clone my git repository using <code>git svn clone</code>. However, I have changes on the master branch in my old git repository that I was not able to commit to svn using <code>git svn dcommit</code>. I'd like to replay these changes on the new repository cloned with git svn. I think I could probably export a patch-set using <code>git format-patch</code>, and then replay these changes on the new repository but I'm not entirely sure how to do this, and I wonder if there's an even easier or more elegant way to accomplish this.

Easiest way to replay commits on new git repository

我一直在使用git-svn，最近，我在尝试提交时遇到错误(我认为这是由于libneon中的一个bug造成的，但这超出了这个问题的范围)。解决方案是使用git svn clone重新克隆我的git存储库。然而，我在我的旧git库中的主分支上有一些更改，我无法使用git svn dcommit将这些更改提交到svn。我想在...

问在新的git存储库上重放提交的最简单方法
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在新的git存储库上重放提交的最简单方法EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在新的git存储库上重放提交的最简单方法
EN