git-subtree冲突从中央回购时拉 [英] git-subtree conflict when pulling from central repo

问题描述

我有几个项目依赖于同一个库，为此我想在每个项目中使用git-subtree来维护一个单独的git存储库。例如，在每个项目中，我都可以做到：

pre $ git subtree add --prefix = lib1 / path / to / lib1.git master
project2 $ git subtree add --prefix = lib1 /path/to/lib1.git master

现在在开发project1的过程中，我对lib1进行了一些更改，比如lib1 / file1.c，并将其推回到中央仓库：

  project1 $ git add lib1 / file1.c 
 project1 $ git commit -m更新到lib1
 project1 $ git subtree push --prefix = lib1 /path/to/lib1.git master 
  

到目前为止，这么好。但是现在我想更新project2的lib1副本。所以我尝试：

  project2 $ git subtree pull --prefix = lib1 /path/to/lib1.git master 
自动合并lib1 / file1.c 
 CONFLICT（内容）：合并lib1 / file1.c中的冲突
自动合并失败;修复冲突，然后提交结果。 
  

发生了什么事？我确定没有对project2下的任何lib1文件进行更改，为什么这里会出现冲突？

冲突是半空的，就像那些在此问题。所有东西都在一个单一的系统（OS X）中被拉/推，所以我知道在那里建议的行结尾没有问题。

当然，这是一个常见的用例为git子树，并有一个简单的答案，我只是看不到。请帮助！

编辑：我找到了一个令人满意的解决方法：在对子树进行更改后立即需要重新运行子树pull：

  project1 $ git subtree push --prefix = lib1 /path/to/lib1.git master 
 project1 $ git subtree pull --prefix = lib1 /path/to/lib1.git master 
  

即使没有它会发现一些东西，并进行合并提交。然后，在其他地方做出一些改变后，第二次从中央回购中撤出时，冲突不会发生。但是如果我忘记在推后立即运行拉，下一次拉就会发生这种冲突。

现在我的问题是，为什么这会起作用？ git-subtree跟踪推送的方式有缺陷吗？或者我缺少什么？

解决方案

好吧，它似乎是git-subtree中的一个bug。我评估它是否符合我的需求，
放弃了。基本上，git-subtree push会改变提交消息，从而改变提交的SHA1。您必须合并额外的提交，这些提交会引入完全相同的更改，但由于已更改的提交消息而具有不同的SHA1哈希值。 GIT会正确处理双重合并（再次合并相同的更改），因此它会默默注意合并。

有人必须解决它！

I have several projects that depend on the same library, for which I'd like to maintain a separate git repository to be managed with git-subtree within each project. So for example, within each project I can do:

project1$  git subtree add --prefix=lib1 /path/to/lib1.git master
project2$  git subtree add --prefix=lib1 /path/to/lib1.git master

Now in the course of working on project1, I make some changes to lib1, say lib1/file1.c, and push this back to the central repo:

project1$  git add lib1/file1.c
project1$  git commit -m "updates to lib1"
project1$  git subtree push --prefix=lib1 /path/to/lib1.git master

So far, so good. But now I'd like to update project2's copy of lib1. So I try:

project2$  git subtree pull --prefix=lib1 /path/to/lib1.git master
Auto-merging lib1/file1.c
CONFLICT (content): Merge conflict in lib1/file1.c
Automatic merge failed; fix conflicts and then commit the result.

What's going on? I know for certain that no changes were made to any of the lib1 files under project2, so why should there be a conflict here?

The conflicts are half-empty, like those reported in this question. Everything is being pulled/pushed within a single system (OS X), so I know there's no issue with line endings as suggested there.

Surely this is a common use case for git-subtree, and has a simple answer I just can't see. Please help!

EDIT: I found an unsatisfying workaround: immediately after pushing changes to the subtree, I need to re-run subtree pull:

project1$  git subtree push --prefix=lib1 /path/to/lib1.git master
project1$  git subtree pull --prefix=lib1 /path/to/lib1.git master

Even though there were no changes, it will find something, and do a merge commit. Then, after making some changes elsewhere, the conflict won't happen the second time I pull from the central repo. But if I forget to run pull immediately after pushing, the next pull will get this conflict.

So now my question is, why does this work? Is there a bug in the way git-subtree tracks pushes, or am I missing something?

解决方案

Well, it seems to be a bug in git-subtree. I evaluated it for my needs and gave up. Basicaly, git-subtree push alters commit messages and thus, SHA1 of commit changes. You have to pull to merge additional commits which introduce exactly the same changes but just have different SHA1 hashes due to altered commit messages. GIT handles double merges (merging same changes again) correctly, so it silently notes the merge.

Someone has to fix it!

这篇关于git-subtree冲突从中央回购时拉的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！