从通用差异文件导入更改到git仓库

3
我正在尝试将一个专有且复杂的源代码控制系统中的更改导入到git存储库中。我目前是通过运行一个脚本来实现的,该脚本仅按顺序同步每个修订版本并将其提交到git存储库中,但由于各种原因,这已经变得不可行。
对于每个修订版本,我可以获得描述更改的通用差异。对我来说,似乎这应该足以将历史记录导入到git中,但是我无论如何都无法弄清楚如何让git这样做。看起来我需要在git-apply和git-fast-import之间使用某些东西。也许我应该从先前版本和差异构建文件内容,然后使用git-fast-import?或者我应该将差异格式化为git补丁,将其保存为文件,然后使用git-apply?
有没有人有好的想法可以帮助我?
编辑:同步和提交变得不可行的原因有两个:
首先,服务器维护您已编辑的文件列表。很难自动同步已编辑的文件,因此在更新时撤消我的更改。我们有一个检入队列系统,只有当排在您前面的人没有与您相同的文件“正在编辑”时,才允许您检入。因此,在更新时将文件“取消编辑”会创建一个窗口,看起来人们可以安全地超越您。
其次,所有分支都存储在同一个存储库中,并且我们广泛使用分支。同步所有内容很容易并且有效,但仅同步一个目录(即我所在的分支)似乎有缺陷。如果我同步所有内容,则其他分支会在我不想要它们的情况下更新。通常这不是问题,但我们还有另一个工具,这使事情变得有点复杂。

哦,希望修改答案已经完成了。 - Jan Hudec
你能告诉我们是哪个系统吗?不是ClearCase或Synergy吗?也许有人知道这个特定的系统并可以告诉你如何在不同步任何内容的情况下获取完整的文本(大多数系统包括ClearCase都有一个命令,可以获取特定文件的特定版本,而不需要检查该文件,如果你找到了其中之一,你可以使用它进行快速导入)。 - Jan Hudec
你说得对,那将是完美的!但我怀疑很少有人真正了解它——它被称为“Source Depot”,是微软使用的内部工具。据我所知,它是Perforce的一个非常古老的分支。 - Ben Hymers
2个回答

4
  • The apply command that takes a unified diff and applies it (i.e. there is no "git patch format", it simply unified diff; also git apply - will happily read standard input, so no need to save anything).
  • The am command takes an mbox-formatted file with patches and applies and commits each of them. You might be able to easily generate this; it's simply:

    From au@th.or Mon, 23 May 2011 14:49:12 +0200
    From: au@th.or
    Date: Mon, 23 May 2011 14:49:12 +0200
    Subject: First line of commit message
    Content-length: <bytes-until-next From>
    
    Other lines of commit message
    ---
    unified diff
    

    concatenated for all the revisions.

  • It indeed seems fast-import does not accept diffs, but can't you just ask the source system to give you the content of the revision instead (that would handle binary files for which unified diff can't be constructed)? If not, you can ask fast-import to give you the previous content (with cat-blob command), patch it and feed it in again.

啊,我甚至没有考虑过二进制文件。你说得对,我不能使用差异来导入二进制文件的更改。我可以获取修订版本的内容,但这很棘手(这就是我以前做的)。不过,获取单个文件时并不那么棘手。所以我现在想的是,我使用 git apply 导入文本文件更改,然后在每个修订版本中检查是否有任何二进制修改,然后同步这些文件并修改提交。我现在会调查一下。 - Ben Hymers
好的,那似乎不是完全可靠的,版本控制系统有一些奇怪的行为。回到起点 :) - Ben Hymers

3
我不知道你所说的“各种原因导致这种方法行不通”是什么,但我在工作中已经成功地做了这件事一段时间了,所以我很熟悉其中的陷阱。关键是将上游代码保留在一个单独的分支中,这样你就可以随时进行同步和git commit而不会产生冲突。我使用我的主分支来完成这个目的。我从特性分支检查新功能的工作流程如下:
  1. git checkout master
  2. 同步到集中式版本控制系统
  3. git add -A
  4. git commit -m "从上游同步"
  5. git merge feature
  6. 检入到集中式版本控制系统
  7. git checkout -b nextfeature
我不费心去获取每一个上游版本的修订,但你可以通过为每一个上游修订执行步骤2-4来实现。

是的,这基本上就是我当前脚本所做的事情!包括为每个版本重复2-4(我喜欢有历史记录,这样我就可以把问题归咎于同事)。我刚刚更新了我的问题,说明了同步的问题。我想避免同步其他版本控制系统。 - Ben Hymers
好的,我将继续这条路线,因为似乎没有更好的方法来解决它。我只需要改进我的脚本,使其自动执行取消编辑和重新编辑操作,以最小化我没有明显更改的时间窗口。我已经找到了解决更新其他分支问题的方法 - 原来只是语法错误。在这样一个过时的系统中很容易犯这种错误! - Ben Hymers

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接