StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
16751956
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-05-25T17:08:43.520
FavoriteCount
0
LastActivityDate
2013-05-25T17:35:17.743
LastEditDate
2013-05-25T17:35:17.743
LastEditorUserId
0
OwnerUserId
0
ParentId
7541321
PostTypeId
2
Score
2
ViewCount
0
LastEditorDisplayName
user456814
text
Body
I'm not sure if this is the nature of your problem, but by default, <code>git log</code> 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 <a href="http://git-scm.com/docs/git-log" rel="nofollow">the <code>git log</code> docs</a>: <blockquote> 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: <code>Default mode</code> 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). </blockquote> Instead of using the default mode, you can pass in the <code>--full-history</code> flag on your file and see if the "missing" commit shows up that way: <pre><code>git log --full-history -- backend/theimportantfile.js </code></pre> From the <code>git log</code> docs: <blockquote> <code>--full-history</code> Same as the default mode, but does not prune some history. </blockquote> <h3>Edit</h3> I know this works sometimes because I experienced a situation where I had a commit <code>X</code> in <code>master</code> that contained a change to a file <code>theFile</code>. Commit <code>X</code> was then cherry-picked into <code>anotherBranch</code> by a coworker, so let's call the new commit <code>Y</code>. Then <code>anotherBranch</code> was merged into <code>master</code>. When we did <pre><code>git log -- theFile </code></pre> we would not see <code>Y</code> in the list of commits, just <code>X</code>, but when we used <pre><code>git log --full-history -- theFile </code></pre> only then would both <code>X</code> and <code>Y</code> show up. I guess Git didn't show <code>Y</code> by default because it introduced an identical change to the final state of the commit tree, since it was cherry-picked from <code>X</code>.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POHow does a commit disappear from the log of one file?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. This table or related slice is empty.
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.