Git changes being lost - why?

Question

Our development team is using git and we\'ve lost changes to files at least twice recently. We are using private Github repos.

In the current case, we can go back throug

Answer 1

I would like to add my few words. I lately noticed very strange behavior in git. My team had big problems because of that. I don't know how it happened but it seems that history in my repo is inconsistent.

Little illustration:

commit XXXXXXXX:

Line "bar" was added to file foo.

...work in progress...

lots of commits later(let's say about 100):

Line "bar" no longer exists in this file!!

Investigation:

1.I inspected history of file with:

git log foo and gitk foo

I even compared consecutive blobs from every commit with external tool(gvimdiff). It's interesting thing that I found two commits(let's call them YYY and ZZZ). Blob of file foo from commit YYY consisted "bar" but blob from ZZZ didn't.
When I inspected commitdiffs of those commits with gitk(and gitweb) I noticed that there is no operation of removing line "bar" in ZZZ. Is it possible that there was some commit in between and dissolved in thin air?
Or maybe commit ZZZ just removed my line and diff tool embedded in git(or gitk) is broken?

2.I searched for commits which could delete this line with "git log -S", something like:

git log -S'bar' -- foo

It turns out that this line was never deleted. As a matter of fact it was added two times. First time when it was introducted to project and second time when it was added again as an urgent bugfix.

I really like using git and even persuaded few friends to use it but if that kind of magic continue to happen, I will have to start searching for alternatives.

Answer 2

Had this issue and found the following snippet helped in analysis:

git for-each-ref --sort=-committerdate refs/heads/ --format='%(HEAD) %(color:yellow)%(refname:short)%(color:reset) - %(color:red)%(objectname:short)%(color:reset) - %(contents:subject) - %(authorname) (%(color:green)%(committerdate)%(color:reset))'

This allows one see the last commit to the repo (sort=-committerdate) in all branches (refs/heads/).

• sample observation:

  feature/blah_a - 9e492d9 - done b4 but committed l8r - (Sat Sep 15 14:29:53 2020)
  feature/blah_b - f98db7a - something - (Sat Sep 26 11:38:42 2020)
  feature/blah_c - 4ab7ee7 - somethang - (Tue Sep 24 17:38:25 2020)
  

  The reader will notice that feature/blah_a predates others but was merged later causing 'loss' of intervening check-ins.

Another 'easy to remember' snippet is:

git log -20 --date=iso --pretty=format:'%cd %h %d'

While its output is terse, it gives a quick snapshot indicating if HEAD commit predates later references.

Answer 3

My guess is that there are different configuration among committers, perhaps someone is missing an autocrlf configuration.

Git somehow considers completely different two revisions of the same file, thus overwriting the old one with newer changes from another branch.

If a three-way merge (default recursive one) finds two completely different childs (ie because of CRLF misconfiguration) the merged result will be the most recent one, with no conflicts.

Answer 4

Similar thing happened to my team too.

Lesson learned: when you pull, you should be careful about merge conflicts. If there're conflicts on pull, git doesn't commit merged changes into your local repo and you must do this after you resolve the conflict. Otherwise, while pushing, you will overwrite remote repo with your local copy NOT containing changes of people did in remote before you pulled. This explains some 'strange files' you might see uncommitted but you're sure that's not your changes - this is indication of a merge conflict on 'pull' and - again - you must commit these changes to local after you resolve the conflict and then push to remote.

If you have no conflicts in merge on pull - no issues with lost changes arise. Because git fetches, merges and commits to your local copy, and 'push' then propagates these merged changes to remote.

Answer 5

I have had similar issues where in the general log I can see the changes I made to a file, but when I check the specific log for the file, those changes don't show up, only those of my coworker. I am pretty sure this is because my coworker messed up the merge somehow... But I still wish this would show up in the log.

Answer 6

I managed to reproduce an instance of this in Visual Studio.

In the conflict resolution screen in VS, once you finish picking the changes from both branches, if you don't manually save the file before clicking "accept merge", it just uses the left (old) version without prompting for lost changes, as it would in other circumstances.