如何获得git自动合并文件列表 [英] How to get list of git auto merge files

问题描述

有没有办法确定哪些文件通过'git merge'成功自动合并 AFTER 用户解决了文件冲突并执行了git add / commit？如果任何成功自动合并的文件都由用户在同一次提交中更新，那么也很高兴知道这一点。我有一个预先接收的钩子，只需要在手动合并的文件上运行。

然后根据说明做出解释。

评论，我会说没有完美的答案，但你可以通过简单地重复合并来获得一个近似值，这个值可能足够好了， - no-commit 以防止合并完成，然后使用 git ls-files -u 来查找哪些文件当前未被合并：

  $ git checkout< first-commit-id> 
 [输出表示分离的HEAD] 
 $ git merge --no-commit< second-id> 
 [输出包括任何合并问题] 
 $ git ls-files -u 
  

git ls-files 的实际输出取决于合并冲突。例如，修改/修改合并冲突（在 fileB 中）：

  100644 7531cd0643738673e94e850c07a681aedd008bca 1 fileB 
 100644 85159a3450148691cd6eec96eb06263240990850 2 fileB 
 100644 bbf71554709c5a9ae8d253b8e15270534f40e3f7 3 fileB 
  

，但在main分支中存在重命名/删除冲突（ fileB 重命名为 fileE ），但在side 分支被合并）：

  100644 7531cd0643738673e94e850c07a681aedd008bca 2 fileE 
  

（这里在这种情况下没有阶段1或3变体）。可能还有其他组合：请参阅 git read-tree 文档，并特别注意3-way merge部分。

来自 git ls-files -u 的输出（如果一切尽可能合并，git可以告诉这是空的 - 这并不意味着合并是正确的，甚至可以如果git真的对语义错误 - 但它是git现在可以自动执行的操作，这大概与git自动执行的操作相同），则中止正在进行的合并并恢复相应的分支：

  $ git merge --abort 
 $ git checkout< original-branch> 
  

如果（如pre-receive hook所示），这一切都在 - bare repository，你将需要一个临时工作树（或整个克隆）来执行合并，我没有时间在这里做实验。 / p>

有问题的两个SHA-1，您需要 git checkout ，只是合并的两个父母。 （请注意，所有这些都假定为2-parent合并：章鱼合并是正确的。）

如果执行合并的人用运行 - 我们的或者 -X 选项，这将不会重复他们所做的并可能会给你一个无用的答案，这就是为什么这个无论如何都不完美。尽管如此，我怀疑这是最好的，你可以完全自动化。

（另外请注意，如果你想要一些可能有意义的细微变化，你可能只需要使用 git read-tree -m ，而不是完整的 git merge 。这只是基于我的怀疑意图在这里，我也认为无论你提出的是什么，最好都可能是边际效用，而你最好是让用户在推送之前自己检查一下自己的东西。）

Is there a way to determine what files were auto merged successfully by 'git merge' AFTER the user has resolved file collisions and performed a git add/commit? If any of the successfully auto merged files were updated by the user in the same commit it would be nice to know that too. I have a pre-receive hook that only needs to be run on files that were manually merged.

解决方案

OK, based on clarification comments, I'd say that there's no perfect answer, but you can get an approximation that's probably good enough by simply repeating the merge, with --no-commit to prevent the merge from completing, then using git ls-files -u to find which files are currently unmerged:

$ git checkout <first-commit-id>
[output indicates detached HEAD]
$ git merge --no-commit <second-id>
[output includes any merge issues]
$ git ls-files -u

The actual output of git ls-files varies depending on the merge conflict. For instance, with a modify/modify merge conflict (in fileB):

100644 7531cd0643738673e94e850c07a681aedd008bca 1   fileB
100644 85159a3450148691cd6eec96eb06263240990850 2   fileB
100644 bbf71554709c5a9ae8d253b8e15270534f40e3f7 3   fileB

but with a rename/delete conflict (fileB renamed to fileE in "main" branch, but deleted in "side" branch being merged-in):

100644 7531cd0643738673e94e850c07a681aedd008bca 2   fileE

(here there's no stage 1 or 3 variant in this particular case). Additional combinations are possible: see the git read-tree documentation and pay special attention to the "3-way merge" section.

Once you have the output from git ls-files -u (which is empty if everything merges cleanly as far as git can tell—this doesn't mean the merge is correct, it could even be total garbage if git is really wrong about the semantics—but it's what git can do automatically now, which is presumably the same as what git could do automatically then as well), abort the in-progress merge and restore the appropriate branch:

$ git merge --abort
$ git checkout <original-branch>

If (as "pre-receive hook" suggests) this is all being done in a --bare repository, you'll need a temporary work-tree (or entire clone) in which to perform the merge, which I don't really have time to experiment with here.

The two SHA-1s in question, that you need to git checkout, are simply the two parents of the merge. (Note that all this assumes a 2-parent merge: octopus merges are right out.)

If the person doing the merge had run with -s ours or some -X option, this won't repeat what they did and may give you a non-useful answer, which is why this is not perfect by any means. I suspect it's the best you can get fully automated, though.

(Also note that if you want some slight variations that might make sense, you might want to just use git read-tree -m alone, rather than a full git merge. This is just based on my "suspicion of intent" here. I also think that whatever you come up with may be of marginal utility at best, and you might be better off just having your users check things themselves before they push.)

这篇关于如何获得git自动合并文件列表的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！