Reputation: 79
I found a very strange phenomenon in GitHub.
In short, a line in a file was changed without any commits.
If I browse the repository at a given point in history, and then the next point in history, I can see that one line of a file changed. But when I view the commit that changed the repository from point 1 to point 2, there is nothing in it for that file.
Earlier, I added a commit that changed just that line the other way around, so it looks like the earlier commit just disappeared without any trace. To my knowledge, in git, nothing can change without a commit. Am I wrong?
Unfortunately, the repo is private, so I cannot share it, but here are some screenshots:
In file Models/Sql.Andris.cs
I changed the ending of a line from "50" to "250" with a commit. Then, a few commits later it was changed back to the original "50". See the codes below.
The bottom red rectangle shows the commit that changed the line from "50" to "250"
At the middle red rectangle the "250" is still there
At the top red rectangle the "250" is changed back to "50"
There is nothing else in this commit.
This is the file Models/Sql.Andris.cs
.
This is the same file Models/Sql.Andris.cs
.
NB: The last line still ends with 250);
This is the same file Models/Sql.Andris.cs
.
NB: The last line ends with 50);
Note that the commit does not have anything from the file Models/Sql.Andris.cs
This phenomenon caused a bug in my application in a pharma environment, which means I must explain the deviation to the authorities, and I have to come up with a solution so that it never happens again. I am stuck, as I don't understand how this could happen, and I do not know how I can prevent it from happening in the future.
Do you have any idea what I missed during my investigation that could explain what happened?
Is there anything I can do to prevent it from happening again?
Any hints will be appreciated!
Upvotes: 1
Views: 64
Reputation: 16373
I assume that merging caused the problem. When two branches are merged, a merge commit is created. That merge commit has two parent commits (the two branches that are merged together). After merging, the commits of both branches can be found in the history.
For example, assume commits like this (top means newest):
X
|
M
|\
A B
| |
C D
|/
E
From commit E, two commits C and D were created. Later, those commits were merged together with the merge commit M. X was created after the merge.
GitHub doesn't show that graph in the commit history. Instead, it just shows the commits. If commit C changed something, it might happen that B is shown after C in GitHub so B would not have the change but it would reappear in X.
In other words, GitHub might show it as (top means newest)
X
M
B
D
A
C
E
but B and D don't know of the changes in A and C.
In your case, it would be possible that something happened while merging #67
(which created commit 27a9506
) and the merge commit somehow didn't show it. Another possibility would be that the commits 14ae7b5
and 27a9506
are from one branch and the commit 9d786f2
is from another and those commits were merged in a future merge commit. GitHub would show the commits of both branches together but the "newer" commit (according to GitHub) doesn't know about the older ones. In that case, the change should be visible in some later commit.
Git provides tools that give more insight.
For example, the command git log --graph
shows you all commits in a graph so you know where which commit originates from and see dependencies of commits.
Another useful command is git blame
. When entering git blame <file>
, it shows you what commit is responsible for every line in that file. GitHub also shows you that when clicking on the Blame
button on the top of files.
Those tools can help you getting information about a git repository and diagnose problems/unclarities like this.
I am only making assumptions as I cannot see your actual code/commits.
Upvotes: 2