0

Team Member 1 committed some new files to our repo today, followed by another commit by Team Member 2. Looking at the two commits, the second didn't overwrite the first. It didn't touch the same files. It didn't delete anything, just modified a few unrelated files, and yet somehow the files from Team Member 1 got deleted from the repository.

How could this happen? How could a file be removed from the repo without a paper trail?

Deeply puzzled here...

benjamin.keen
  • 1,936
  • 1
  • 20
  • 29
  • 2
    Can you provide more information about exactly what the history looks like and how you determined that the missing files weren't changed in a commit? If there was a evil merge involved which dropped the files it may not show up in git log. – asm Jan 24 '14 at 00:08
  • Thanks, Andrew! Interesting the log may not show everything (!). What other info about the history would you like? The first commits just had 2 modified files; 2 new files. The second had 15 or 20 modified files (totally different files). btw, I also ran a "git log -- missing-file.js" command on one of the missing files but there's nothing returned - like it never existed. – benjamin.keen Jan 24 '14 at 00:14
  • 2
    Changes introduced by an [evil merge](http://stackoverflow.com/questions/1461909/evil-merges-in-git) sometimes don't show up in `git log` but will in `gitk`. Another possibility is that when making the second commit the first was rebased and modified? Can you check if the SHA Member #1 originally committed matches the SHA of that commit now in the repository? You could post an edited screenshot from gitk but it sounds like the commits are just inline? – asm Jan 24 '14 at 00:27
  • Great tip with gitk, thanks! Very useful. But it doesn't mention the missing files in the second commit. Yes, I think that Member 2 may well have done a rebase (I think that's the default merge behaviour we have set up). I don't quite follow the SHA commit difference though. In gitk, the commit has the same SHA as what appears in github, if that's what you mean? – benjamin.keen Jan 24 '14 at 01:03
  • do you know the commit, of which the separation had appear? – Малъ Скрылевъ Jan 24 '14 at 05:17
  • @benjamin.keen If member 2 did a rebase which changed the commit (such as dropping files) the SHA will be different. If member 1 looks in their history and finds the SHA of the commit _when they created it_ take that and check it against what you see in the repository. They may want to use `git reflog` for this. – asm Jan 24 '14 at 13:18

0 Answers0