File: git_rename_detection_on_file_move.mdwn

package info (click to toggle)
git-annex 5.20141125
  • links: PTS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 37,828 kB
  • ctags: 583
  • sloc: haskell: 42,582; sh: 1,080; ansic: 498; makefile: 316; perl: 125
file content (14 lines) | stat: -rw-r--r-- 725 bytes parent folder | download | duplicates (11)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
It's unfortunate that git-annex sorta defeats git's rename detection.

When an annexed file is moved to a different directory (specifically, a
directory that is shallower or deeper than the old directory),
the symlink often has to change. And so git log cannot --follow back
through the rename history, since all it has to go on is that symlink,
which it effectively sees as a one line file containing the symlink target.

One way to fix this might be to do the `git annex fix` *after* the rename
is committed. This would mean that a commit would result in new staged
changes for another commit, which is perhaps startling behavior.

The other way to fix it is to stop using symlinks, see [[todo/smudge]].
[[!tag confirmed]]