Git格式的修补程序/捆绑包，用于人可读的sneakernet“；“拉/推”；

我有两个房间，我在其中使用git维护一些源代码，一个是“开发”房间，大多数开发都在这里进行，另一个是“部署”房间，我们在其中实际使用软件。部署室中不可避免地也会发生一些变化。我希望两个房间在git中共享相同的历史

限制：

出于安全原因，这两个房间没有网络连接

只有文本文件（人类可读）才能离开部署室

使用

git bundle

将更改移动到部署室非常简单，并跟踪我们移动到部署室的最后一次提交。由于仅限文本的限制，将更改移出文件室更加困难

目标：在我的两个未连接的房间之间来回移动提交，就像发生了一个

git pull

，也就是说，两个房间中都有相同的SHA1散列

到目前为止：

• 我尝试了

  git format patch

  将更改从deploy移回dev，但这不会记录合并，因此需要为每个连续的更改集生成不同的补丁集，并记录如何复制其间发生的确切合并提交。有一些讨论，但这似乎没有捕捉到真正的祖先，只有变化。似乎补丁的格式不够丰富，无法提供必要的信息

• 一些bundle-to-text脚本可用于将bundle转换为非压缩和人类可读（ish）格式（下载后再转换），但我没有发现这样的脚本存在的证据

• 也许可以编写一个脚本，将历史从某个共同的祖先遍历到最新的提交，然后a）制作一个补丁，或者b）重新创建一些常见引用的合并

回退：我总是可以将部署室中的提交压缩成一个原始补丁并打破历史记录，但是从dev->deploy进一步下载会破坏任何现有的工作副本。不理想

更新：

---

我相信

git fast export

可以满足我的需要，尽管大多数示例都是在整个存储库中使用，而不是像

git bundle

这样的部分历史记录。我有一个工作玩具示例，其中我可以将部分历史导出到过期的克隆中，但它需要我手动编辑快速导出输出，以便在第一次提交时添加一个

from

。如果不进行此修改，导入将创建不同的SHA1，然后投诉

未更新refs/heads/master（新技巧不包含我从未找到完美的解决方案，但我们现在所做的似乎很有效。主要缺点是部署室内的提交最初有一个SHA1，然后在与开发室合并后更改为不同的SHA1。好消息是
git
很容易将它们识别为相同的提交s可以通过它们进行合并


我们必须跟踪3个检查点：

dev/master
这是开发室中最新开发的
deploy/master
这是部署室中最新开发的
dev\u deploy\u common
这是两个历史记录共享的最后一次提交



当我们将代码从dev移动到deploy（使用捆绑包）时，我们将提交作为部署室内
dev\u deploy\u common
分支的一部分带入（
git pull
进入
dev\u deploy\u common
），然后从
deploy/master
执行
git merge dev_deploy_common
，然后在此解决冲突

当我们将代码从deploy移动到dev（必须是一个文本文件）时，我们需要执行一些额外的步骤：

首先，我们将
deploy/master
重新设置到
dev\u deploy\u common
上，这样我们的所有补丁都是连续的。这通常很容易，因为我们已经处理了合并过程中的任何冲突，这些冲突是在将捆绑包从dev带到部署时发生的

其次，我们使用

git format-patch -M25 -C25 --find-copies-harder -k --ignore-if-in-upstream

-M25-C25--find copies harder
选项只是减少了输出文本的大小。
-k
选项保持提交主题的完整性。
--ignore if in upstream
将我们的提交限制为只提交新的主题，因为
dev_deploy_common

其结果是一个补丁的
patchset.txt
集合。该文件可以手动查看，然后移动到开发室

在开发室中，我们使用以下命令导入补丁集：

git am -k -3 --keep-cr --committer-date-is-author-date patchset.txt

不幸的是，尽管我们使用了所有可以保持补丁完全相同的命令，但一些属性发生了变化，主要是提交者。因此，“相同”提交在开发室和部署室中将有不同的SHA1。这种差异将持续到我们将包移回部署室为止

将捆绑包从开发人员移动到部署人员时，
merge
操作（通常）会识别相同的补丁，并用开发人员历史记录中的补丁无缝地替换提交。请参阅步骤1

你能做到这一点吗？我和你有完全相同的限制，并且得出了相同的结论：为了支持这一点，必须开发其他脚本。我刚刚回答了我自己的问题，概述了我们的工作。我很惊讶没有ASCII版本的
git bundle
，因为这确实是在这种情况下，最好是在。您是否尝试关闭压缩以查看捆绑包输出结果？无论如何，感谢您提供此信息。@WalterNissen我没有看到“无压缩”git bundle中的选项。这里似乎描述了格式：尽管我还没有找到一种方便的方法来获取未压缩的版本。假设“压缩数据”只是Zliba，我想我可以制作一个读写器来实现这一点