【问题标题】:Import changes into a git repository from universal diff从通用差异将更改导入 git 存储库
【发布时间】:2013-06-10 16:26:17
【问题描述】:

我正在尝试将更改从一个源代码控制系统(专有且复杂)导入 git 存储库。我目前正在通过运行一个脚本来执行此操作,该脚本只是按顺序同步到每个修订版并将其提交到 git 存储库,但由于各种原因,这已变得不可行。

对于每个版本,我都可以获得描述更改的通用差异。对我来说,这似乎足以将历史导入 git,但我一生都无法弄清楚如何让 git 做到这一点。看起来我需要介于 git-apply 和 git-fast-import 之间的东西。也许我应该从以前的版本和差异构造文件内容,然后使用 git-fast-import?或者我应该将 diff 格式化为 git 补丁,将其保存为文件,然后使用 git-apply?

有人对我有什么好主意吗?

编辑:同步和提交变得不可行的原因有两个:

首先,服务器会维护您已编辑的文件列表。与编辑过的文件同步不容易自动化,所以我在更新时恢复了我的更改。我们有一个签入队列系统,仅当您面前的任何人都没有与您“正在编辑”的任何相同文件时,您才允许您签入。因此,将文件“关闭编辑”进行更新会创建一个窗口,看起来人们可以安全地跳到你前面。

其次,所有分支都存储在同一个存储库中,我们大量使用分支。同步一切都很容易并且有效,只同步一个目录(我所在的分支的目录)似乎有问题。如果我同步所有内容,其他分支会在我不希望它们时更新。这通常不会成为问题,但我们有另一个工具,它使事情变得……复杂。

【问题讨论】:

  • 哦,希望编辑完答案。
  • 你能告诉我们它是哪个系统吗?不是 ClearCase 还是 Synergy?也许有人知道特定的系统,并且可以告诉您如何在不同步任何内容的情况下从中获取全文(包括 ClearCase 在内的大多数系统都有一个命令可以在不检查文件的情况下获取特定文件的特定修订版,如果您找到了,您可以与快速导入一起使用)。
  • 你说得对,那就太完美了!我怀疑有很多人很了解它——它被称为“Source Depot”,这是微软使用的一种内部工具。据我了解,这是 Perforce 的一个非常古老的分支。

标签: git diff


【解决方案1】:
  • apply 命令采用统一差异并应用它(即没有“git 补丁格式”,它只是统一差异;而且git apply - 将愉快地读取标准输入,因此无需保存任何内容)。
  • am 命令采用带有补丁的 mbox 格式文件,并应用并提交每个补丁。您也许可以轻松生成它;很简单:

    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
    

    连接所有修订版。

  • 似乎fast-import 确实不接受差异,但你不能只要求源系统给你修订的内容(这将处理无法构建统一差异的二进制文件)吗?如果没有,你可以让fast-import给你之前的内容(用cat-blob命令),打补丁然后重新输入。

【讨论】:

  • 啊,我什至没有考虑二进制文件。你是对的,我不能使用差异来导入对二进制文件的更改。我可以得到修订的内容,是的,但它是有问题的(这是我之前做的)。但是,在获取单个文件时,这并不是那么成问题。所以我现在想的是我使用git apply 导入文本文件更改,然后在每次修订时检查是否有任何二进制修改,然后同步这些文件并修改提交。我现在就调查一下。
  • 好吧,这看起来并不完全可靠,VCS 有一些奇怪的行为。回到广场 1 :)
【解决方案2】:

我不知道您的“各种原因导致它变得不可行”是什么,但我已经在工作中成功地做这件事已经有一段时间了,所以我很熟悉其中的陷阱。诀窍是将您的上游保持在一个单独的分支中,这样您就可以始终进行同步和git commit,而不会产生冲突。为此,我使用我的主分支。我从功能分支签入新功能的工作流程是这样的:

  1. git checkout master
  2. 同步到集中式 VCS
  3. git add -A
  4. git commit -m "从上游同步"
  5. git 合并功能
  6. 签入集中式 VCS
  7. git checkout -b nextfeature

我不会费心从上游获取每个修订版,但您可以通过对每个上游修订版执行步骤 2-4 来做到这一点。

【讨论】:

  • 是的,这基本上就是我当前脚本的作用!包括为每个版本重复 2-4 次(我喜欢有历史,所以我可以责怪同事的问题)。我刚刚更新了我的问题,说明同步的问题是什么。我真的想避免同步其他 VCS。
  • 对,我将继续这条路线,因为似乎没有更好的方法可以做到这一点。我只需要改进我的脚本以自动进行取消编辑和重新编辑,以最大限度地减少我没有明显变化的时间窗口。我找到了解决更新其他分支问题的方法 - 原来我只是语法错误。用这样一个过时的系统很容易做到!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-08-10
  • 2021-12-04
  • 1970-01-01
  • 2011-11-08
  • 1970-01-01
  • 2018-02-27
相关资源
最近更新 更多