1

I tried to amend a file and move it to a different folder at the same time but somehow git doesn't track the movement of that file. It sees it as a new file.

christoph@christoph-laptop-16-04-2:~/Documents/Uni/Modules/2016-04-18 Numerik/Vorlesungsfolien$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   Offene Fragen.md

no changes added to commit (use "git add" and/or "git commit -a")
christoph@christoph-laptop-16-04-2:~/Documents/Uni/Modules/2016-04-18 Numerik/Vorlesungsfolien$ git mv Offene\ Fragen.md ..
christoph@christoph-laptop-16-04-2:~/Documents/Uni/Modules/2016-04-18 Numerik/Vorlesungsfolien$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    Offene Fragen.md -> ../Offene Fragen.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   ../Offene Fragen.md

christoph@christoph-laptop-16-04-2:~/Documents/Uni/Modules/2016-04-18 Numerik/Vorlesungsfolien$ git add -A
christoph@christoph-laptop-16-04-2:~/Documents/Uni/Modules/2016-04-18 Numerik/Vorlesungsfolien$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   ../Offene Fragen.md
    deleted:    Offene Fragen.md

christoph@christoph-laptop-16-04-2:~/Documents/Uni/Modules/2016-04-18 Numerik/Vorlesungsfolien$ git commit -m "Added questions regarding Numerik."
[master a2e17f5] Added questions regarding Numerik.
 2 files changed, 4 insertions(+), 2 deletions(-)
 create mode 100644 Uni/Modules/2016-04-18 Numerik/Offene Fragen.md
 delete mode 100644 Uni/Modules/2016-04-18 Numerik/Vorlesungsfolien/Offene Fragen.md

Is there a way to keep track of a file's movement in such a case? (Other than making 2 commits, of course. Maybe committing once after moving the file and then amending the commit after amending the file would work, too.)

UTF-8
  • 575
  • 1
  • 5
  • 23
  • I think it depends on the magnitude of the change, I've successfully edited and "renamed" (moved) a file with git acknowledging it was the same file. There's some console indication of % change. Someone with better understanding should be able to provide a coherent answer. – Jeff Puckett Aug 31 '16 at 20:57
  • Also related: [Handling file renames in git](http://stackoverflow.com/q/2641146/216074), [git fails to detect renaming](http://stackoverflow.com/q/13805750/216074). In general, Git does not track actual file moves/renames. It only tracks snapshots of the repository and as such only actually recognizes when files are added and removed. If a removed file is *similar* to a file that was added, it will visualize this as a likely file move—but that detection only happens in the frontend. It makes no difference whether you see it as a move in `git status` or not. The underlying action is the same. – poke Aug 31 '16 at 21:03
  • @poke I'm not entirely convinced it's an *exact* duplicate considering this question involves a simultaneous modification with the rename. So, @UTF-8, does `git log --follow "Offene Fragen.md"` trace the full history? – Jeff Puckett Aug 31 '16 at 21:14
  • The point is that the way moves work in Git (i.e. they don’t exist), anything that could possibly improve the detection of the move (e.g. reducing the threshold) has only temporary effect on what you see when you look at the command line output. Nothing will have an impact on how Git actually stores it. So either Git is able to recognize it, or it isn’t. If you want to make it easier for Git to recognize the move (later), the only option is to commit the rename separately. – poke Aug 31 '16 at 21:28
  • @JeffPuckettII The command only shows the newest commit (the one you see me make in the command line IO above). The file was definitely tracked before. – UTF-8 Aug 31 '16 at 22:55
  • @poke I originally moved the file via `mv` but saw that git didn't recognize it. (I obviously didn't commit that, though.) That's why I tried `git mv` in the command line IO you can see in the question after undoing the first move. Does `git mv` even do anything besides moving the file in the file system, so is there a difference between `mv` and `git mv`? – UTF-8 Aug 31 '16 at 22:58
  • `git mv` is just a utility command that basically moves the file physically, removes the old location using `git rm` and adds the new location using `git add`. As I explained above, there is no concept of move/rename in Git, it’s just a detection when an added file is similar to a removed file. So it does not make a difference how you get to the situation; once you’re there, Git won’t know (or care) how you got there. – poke Sep 01 '16 at 06:37
  • Does this have a reason? git could just cache the file when it moves it so it has an intermediate point to compare to, therefore improving tracking of files. Furthermore,the file was shown as modified before I moved it,not as a new file. I then told git to move it to a different place and didn't even modify it any more. And it this point, git still behaved perfectly reasonable because it showed `renamed: Offene Fragen.md -> ../Offene Fragen.md` in `git status`. Suddenly not recognizing the renaming any more as soon as I stage the changes to commit them, appears to be very counter-intuitive. – UTF-8 Sep 01 '16 at 10:42

0 Answers0