Git - Commit 是 HEAD 的祖先,但不影响 HEAD,并且不会出现在 gitk

发布于 2024-08-23 08:52:50 字数 945 浏览 6 评论 0原文

让我困惑的文件是 v5/employer/controllers/_employer.php
在第一张图片中,您将看到 Brian 在 14:55:47 的一次名为“提交内容的时间”的提交中更改了文件。

替代文本 http://img96.imageshack.us/img96/850/figure1.png< /a>

但是该提交的唯一子项(第二张图片)是 Brian 在 14:56:45 执行的合并操作,没有显示对该文件的任何更改。但不一样!

替代文本 http://img190.imageshack.us/img190/7787/figure2u.png< /a>

当您在合并操作后查看该文件的实际内容时,您可以看到它与之前的版本不同,但补丁视图中没有显示任何内容。

所以基本上,Brian 在“提交内容的时间”提交中所做的更改丢失了,至少对于该文件来说是这样。

现在,如果我运行 gitk --all v5/employer/controllers/_employer.php,我会得到第三个图像 - 它根本不显示提交!

替代文本 http://img704.imageshack.us/img704/7135/figure3.png< /a>

这是怎么回事?是我们都疯了,还是 git 真的丢失了我们的数据?

The file that's mystifying me is v5/employer/controllers/_employer.php.
In the first image, you'll see that Brian changed the file in a commit on 14:55:47 called "time to commit stuff".

alt text http://img96.imageshack.us/img96/850/figure1.png

But that commit's only child (second image), a merge operation Brian did at 14:56:45, does not show any changes to that file. But it's different!

alt text http://img190.imageshack.us/img190/7787/figure2u.png

When you look at the actual contents of that file after the merge operation, you can see it's different than the version before it, but nothing shows up in the patch view.

So basically, Brian's changes in that "time to commit stuff" commit got lost, at least for that file.

Now if I run gitk --all v5/employer/controllers/_employer.php, I get the third image--which doesn't show the commit at all!

alt text http://img704.imageshack.us/img704/7135/figure3.png

What's going on here? Are we all crazy, or is git really losing our data?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

走野 2024-08-30 08:52:50

是的,它开始看起来像是一个冲突的合并变坏了。作为“提交内容的时间”的子项的合并提交有另一个父项(显然;这是一个合并),并且注释指出 _employer.php 中存在冲突。

我们回去回顾了那次合并中发生的事情。事实证明,我们使用 git gui 的“使用远程版本”来尝试解决冲突,而不是像 meld 这样的外部合并工具,因为冲突确实微不足道。事实证明,该按钮不仅解决了与远程版本的冲突,还将整个文件与其合并的本地或远程版本一起推倒。

由于该文件与其父提交之一相同,因此它不会在该修订版中显示为修改后的文件。起初这让我感到困惑,因为文件在合并到另一个分支后发生了更改。但现实是,我没有在一个分支中合并,而是在合并两个分支,而且它也可能是在文件真正没有改变的另一个方向上的合并。

啊。嗯,这是用户错误(惊讶,惊讶)。将此作为始终使用外部合并工具来解决冲突的警告。

Yep, it's starting to look like it was a conflicted merge gone bad. The merge commit that's a child of "time to commit stuff" has another parent (obviously; it's a merge), and the note states there was a conflict in _employer.php.

We went back and walked through what happened in that merge. It turns out we used git gui's "Use remote version" to try and resolve the conflict rather than an external merge tool like meld, since the conflict was really trivial. As it turns out, that button doesn't just resolve conflicts with the remote version, it bulldozes the entire file with either the local or remote version it's merging from.

And since the file is identical to one of its parent commits, it doesn't show up as a modified file in that revision. That was confusing to me at first, since the file was changed after merging in another branch. But the reality is, I wasn't merging in a branch, I was merging two branches, and it might as well have been a merge in the other direction where the file genuinely didn't change.

Ugh. Well, it was user error (surprise, surprise). Let this be a warning to always use an external merge tool to resolve conflicts.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文