22

I made a commit about a month ago that involved me creating new folder and sub-folders and moving my source code files in between them. I just was looking through my history for the first time since then and realized git has 'lost' history since the original files were deleted and then re-added, I suppose - i.e. when I'm viewing a file in my git GUI (it's under NDA so I can't discuss it directly, but for example, this repository is broken on GitHub too. GitHub clearly shows its detecting the commit as a series of moves.) it only shows history for each file back to when the project folder was reorganized.

After reading a few questions ( Getting Git to Acknowledge Previously Moved Files, How to make git mark a deleted and a new file as a file move?), I'm simply more lost than when I started. It sounds like from those answers that I won't be able to fix this at all? I'd really appreciate any help here.

Community
  • 1
  • 1
refulgentis
  • 2,624
  • 23
  • 37
  • 3
    @JUST: Your opinion is incorrect this time. SO is absolutely the right place for questions about version control. Surely the OP's links to previous git questions suggest this? Just look at the FAQ: "software tools commonly used by programmers". I assume that's your close vote - maybe you should go have a look at the FAQ and the privileges page before you exercise that privilege again. – Cascabel Nov 14 '10 at 15:46
  • @Jefromi: I hear you, but since "tag sets" came up, I stopped this kind of battle ;) See http://blog.stackoverflow.com/2010/11/stack-overflow-homepage-changes/#comment-51797 . They can move up those questions pretty much wherever they want... I will *see* them ;) – VonC Nov 14 '10 at 16:13
  • @VonC: I'd argue we should still try to keep the questions in one place, if not for us, for the people searching for answers. – Cascabel Nov 14 '10 at 16:36
  • @Jefromi: agreed. I recommit myself to this endeavor ;) – VonC Nov 14 '10 at 16:52

7 Answers7

11

In Git there's no the concept of file move.

Some tools, like GitHub, consider a commit containing a file named X that has been deleted and a file named X that has been created a file move.

According to Linus Torvalds, file move is just a special case of refactoring; for this reason Git will not treat it differently. Handling of this special case, like many others, is left to higher-level tools (such as frontends).

For more info on this topic, check this answer from Linus Torvalds.

Gian Marco
  • 22,140
  • 8
  • 55
  • 44
  • 3
    I don't know about Git in general, but Github loses a file's history if you move it. I'm seeing this problem in one of my github repos now where I moved an entire directory structure and all the files in it now show up as having 1 element in their history. – Powerlord Apr 19 '13 at 15:30
  • 1
    The link in your answer is dead,do you have another source? Or can you just post the whole quote? – NomenNescio Sep 22 '16 at 08:01
  • No other source than the link provided.. Seems that the whole http://permalink.gmane.org/ is not working as expected – Gian Marco Sep 23 '16 at 15:41
  • 1
    So the answer is yes, history is lost? – s_baldur Jan 23 '20 at 15:59
  • @sindri_baldur the answer is that git track content, not the actions that has been taken to create the content. So content history is kept, history of operations done on content is not. – Gian Marco Feb 02 '20 at 11:18
  • @GianMarcoGherardi Just looking at the surface: When you change the content of a file, you can see the history of commits that changed the content of file with things like `git log` on the command line or `history` on GitHub. But when you change the name of the file neither seems to work anymore. On GitHub I can only see `File renamed without changes.` but the history from before that is not accessible anymore. – s_baldur Feb 02 '20 at 12:03
6

As far as I see it you want:

git log --follow some_file.cpp

See http://git-scm.com/docs/git-log for details. I am not sure if that is what you want; but in case of git, git tracks content not files. The problem is that determining that information is really expensive and it is assumed that normally you don't need it...

rioki
  • 5,988
  • 5
  • 32
  • 55
3

If you want to move folders around in git, you can use git mv.

I had a bunch of folders in the root of my repository, and wanted to move them into two subdirectories, so I created the two new directories using **mkdir.

Then I moved files and folders one at a time into the new directories like this:

git mv folder1/ newDirectory1/
git mv file1.txt newDirectory2/

etc.

I had a case where I wanted to rename one of the directories to src and I did it like this:

git mv folder2 newDirectory1/src

This resulted in a set of files that looked like this:

repository/
   newDirectory1/
      folder1/
      src/
   newDirectory2/
      file1.txt

After I was finished, I created a new branch called "reorganized" so I wouldn't interfere with work another developer was doing in the master branch. He continued to work on the files, and as he pushed new changes to master, I pulled and merged the changes into my branch, and everything worked as I had hoped. Files that had been moved were referenced properly from their original locations, and received their commits.

Steve W
  • 71
  • 4
2

Did you try settings the config diff.renames?

diff.renames

Tells git to detect renames. If set to any boolean value, it will enable basic rename detection. If set to "copies" or "copy", it will detect copies, as well.

Note: to follow history of a single file across renames, you need to use "git log -p --follow file".

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • It seems that TC has actually deleted a file, and then restored it a revision later (or something like that), which means that Git doesn't detect it as a rename. – erjiang Nov 14 '10 at 16:01
  • I did - no dice. This repository is 'broken' on GitHub too, if I can just get GitHub to read it correctly I'll be happy. – refulgentis Nov 15 '10 at 19:44
0

If you're actually missing revisions from your history (it's not completely clear from your question what's actually missing) and it's only been around a month, you probably still have time -- look at the reflog; it keeps a copy of every reference you have checked out, so if you make a mistake you can get back what you had before.

The default is to keep reflog entries for 90 days, they are expired by git gc.

git help reflog
Andrew Aylett
  • 39,182
  • 5
  • 68
  • 95
  • I should have been more clear – I'm not missing data, but when I try to view the history of a given file in my git GUI, it only shows back to my 'reorganization' commit – refulgentis Nov 14 '10 at 09:03
0

I would run a script that goes through all the objects. You would need to unpack all the pack files first. The script would check the type, if it is a commit you would see if you are the author. Then check the date. List those and grep for the file name that you want. Once you have the commit of interest, create a branch with

git branch RecoveredWork hash-of-your-commit

and see if you have all that you want with

git log RecoveredWork --graph --decorate

from here you may want to do some filter branching, grafting and/or rebasing to link up the history again.

user229044
  • 232,980
  • 40
  • 330
  • 338
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
0

I can think of a few possibilities. If things were just shuffled around, but don't track, then I presume that this was done in two different commits... one to remove and then one to re-add. Create a new branch in the commit before that, load in the next two commits as one commit, and then append everything after that.

If that is not the case, you may need to look at the commits with git log -M -C

Jeff Ferland
  • 17,832
  • 7
  • 46
  • 76