git 快速导入提交顺序
我正在为 Plastic SCM/Git 编写快速导出/快速导入套件，但我发现了一些问题。
正如我从 文档 中读到的：
这种设计允许前端程序 处理无限数量的 同时分支，生成 按顺序提交 可从源数据中获取
但是，实现“导出器”时，我发现您无法引用尚未创建的提交。例如，假设您首先引入合并的提交目标而不是源，然后您只需引用那里的源，但它根本不起作用。
因此，据我了解，“按照从源中可用的顺序生成提交”这句话完全是错误的，并且 git fast-import 确实需要按顺序提供提交，并且引用只能存在于之前引入的对象。
正确吗？
谢谢。
I'm writing a fast-export/fast-import suite for Plastic SCM/Git and I'm finding some issues.
As I read from the documentation:
This design allows a frontend program
to process an unlimited number of
branches simultaneously, generating
commits in the order they are
available from the source data
But, implementing the "exporter" I see that you can't reference a commit that hasn't been created yet. For instance, suppose you introduce first the commit destination of the merge than the source, then you simply reference the source there, but it simply doesn't work.
So, as far as I understand the sentence "generating commits in the order they are available from the source" is simply wrong and git fast-import really need the commits to be supplied in order and references can only exist to objects introduced BEFORE.
Is it correct?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，git-fast-import 需要按从最旧到最新的顺序查看每个分支的提交。您从文档中引用的声明有些含糊不清，因为“它们从源数据中可用的顺序”实际上必须是每个分支增加的时间顺序。
我认为该声明意味着您不必按严格的时间顺序呈现所有分支的所有提交。相反，就像正常使用 Git 一样，每次提交都必须在创建其所有祖先之后创建。
这种方法在如何导入提交方面仍然保留了一定的灵活性。我编写了一个导入程序（针对旧的专有源代码控制系统），它单独处理每个分支的整体（当然，从最旧到最新）。 Git 匹配了不同分支之间的共同祖先，并制作了一个很好的合理的层次结构树，因为每个分支中共同祖先的 SHA1 哈希值是相同的。
Yes,
git-fast-importneeds to see the commits for each branch in order from oldest to newest. The statement you quoted from the documentation is somewhat ambiguous, because "the order they are available from the source data" must in fact be increasing time order per branch.I think that statement means that you don't have to present all the commits across all branches in strictly chronological order. Rather, just like working with Git normally, each commit must be created after all its ancestors have been created.
This approach still leaves a bit of flexibility in how commits can be imported. I wrote an importer (for an old proprietary source control system) that processed the entirety of each branch separately (from oldest to newest, of course). Git matched up the common ancestors between different branches and made a nice sensible hierarchy tree because the SHA1 hashes of common ancestors in each branch were the same.