一个提交如何从一个文件的日志中消失？ [英] How does a commit disappear from the log of one file?

问题描述

所以我对一个文件做了一个改动，把它推到了我们的主库，在那里看到了。大卫从那个回购中拉出来，做了 - 呃，某件事 - 并且看不到我的变化。由于David是一名典型的微软受害者，因此我要求他推动他回购的回购协议，我会在那里看看。

git log --name-only 产生

 提交194b7f5dbb59d29ace340a376f10906752978db5 
合并：484df79 afc2dec 
作者：David Good< [e-mail]> 
日期：Sat Sep 24 11:47:14 2011 -0700 
 
 [David's merge] 
 
 commit afc2dec4a828de05350c39526eeecf9d3a15e465 
作者：Michael< info @ company.com> 
日期：9月24日星期六10:58:54 2011 -0700 
 
 [我的更改] 
 
后端/ theimportantfile.js 
 
提交e4e2f9ce9df3adf5ed0547ed16521eb742cc2ac1 
作者：Michael< [e-mail]> 
日期：星期六9月24日10:47:09 2011 -0700 
 
 [其他某物] 
  

但是 git log backend / theimportantfile.js 产生

  commit eb470fe1792220779b14e90337f74fb216fc9f7f 
作者：David Good< [e-mail]> 
日期：Mon Sep 12 17:20:25 2011 -0700 
 
 [comment] 
 
 commit 63ddd2be020092a4bf65d1eac106ece5fd7fbbd3 
作者：David Good< david @ company.com> 
日期：星期五9月9日16:23:53 2011 -0700 
 
 [comment] 
  

因此根据git， backend / theimportantfile.js 在几周内没有被触及，但它在两个小时前也被afc2dec提交改变了。我怎样才能追踪发生了什么？

解决方案

我不确定这是否是您问题的本质，但默认情况下， git log 有时会过滤掉它认为不是有用或有趣的提交，以便理解提交树的最终状态。从 git log 文档：

有时候您只对历史的某些部分感兴趣，例如修改特定< path>的提交。但是，历史简化有两个部分，一部分是选择提交，另一部分是如何执行，因为有多种策略可以简化历史记录。

以下选项会影响简化的执行方式：

默认模式

将历史简化为解释树的最终状态的最简单历史记录。最简单的，因为如果最终结果是相同的（即合并具有相同内容的分支）它会修剪一些分支。

在默认模式下，您可以传递文件中的 - 完整历史记录标志，并查看missing提交是否显示出来：

  git log --full-history  -  backend / theimportantfile.js 
  

$ b

从 git log 文档：

- 完整历史

与默认模式相同，但不修剪历史记录。

编辑

我知道这有时候很有效，因为我遇到了一种情况，在文件 theFile 中包含变更的 master 中提交 X >。提交 X 然后由同事挑选到 anotherBranch 中，所以让我们调用新的提交ÿ。然后 anotherBranch 合并为 master 。

当我们

  git log  -  theFile 
  

我们不会在提交列表中看到 Y ，只是 X ，但当我们使用

  git log --full-history  -  theFile 
  

只有 X 和 Y 显示向上。我猜Git默认没有显示 Y ，因为它引入了与提交树的最终状态相同的更改，因为它是从 X 。

So I made a change to a file, pushed it to our main repo, saw it there. David pulled from that repo and did -- well, something -- and couldn't see my change. Since David is a typical Microsoft victim, I asked him to push what he had back to the repo and I'd look at it there.

git log --name-only produces

commit 194b7f5dbb59d29ace340a376f10906752978db5
Merge: 484df79 afc2dec
Author: David Good <[e-mail]>
Date:   Sat Sep 24 11:47:14 2011 -0700

[ David's merge ]

commit afc2dec4a828de05350c39526eeecf9d3a15e465
Author: Michael <[e-mail]>
Date:   Sat Sep 24 10:58:54 2011 -0700

[ my changes ]

backend/theimportantfile.js

commit e4e2f9ce9df3adf5ed0547ed16521eb742cc2ac1
Author: Michael <[e-mail]>
Date:   Sat Sep 24 10:47:09 2011 -0700

[ some other thing ]

but git log backend/theimportantfile.js produces

commit eb470fe1792220779b14e90337f74fb216fc9f7f
Author: David Good <[e-mail]>
Date:   Mon Sep 12 17:20:25 2011 -0700

[ comment ]

commit 63ddd2be020092a4bf65d1eac106ece5fd7fbbd3
Author: David Good <[e-mail]>
Date:   Fri Sep 9 16:23:53 2011 -0700

[ comment ]

So according to git, backend/theimportantfile.js hasn't been touched in weeks but it was also changed two hours ago with the afc2dec commit. How can I track down what happened?

解决方案

I'm not sure if this is the nature of your problem, but by default, git log will sometimes filter out commits that it thinks aren't "useful" or "interesting" in order to understand the final state of a commit tree. From the git log docs:

Sometimes you are only interested in parts of the history, for example the commits modifying a particular <path>. But there are two parts of History Simplification, one part is selecting the commits and the other is how to do it, as there are various strategies to simplify the history.

The following options affect the way the simplification is performed:

Default mode
Simplifies the history to the simplest history explaining the final state of the tree. Simplest because it prunes some side branches if the end result is the same (i.e. merging branches with the same content).

Instead of using the default mode, you can pass in the --full-history flag on your file and see if the "missing" commit shows up that way:

git log --full-history -- backend/theimportantfile.js

From the git log docs:

--full-history
Same as the default mode, but does not prune some history.

Edit

I know this works sometimes because I experienced a situation where I had a commit X in master that contained a change to a file theFile. Commit X was then cherry-picked into anotherBranch by a coworker, so let's call the new commit Y. Then anotherBranch was merged into master.

When we did

git log -- theFile

we would not see Y in the list of commits, just X, but when we used

git log --full-history -- theFile

only then would both X and Y show up. I guess Git didn't show Y by default because it introduced an identical change to the final state of the commit tree, since it was cherry-picked from X.

这篇关于一个提交如何从一个文件的日志中消失？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！