Git dynamically computes the file renames (using a "similarity index", see diff -M
option; also -B
and -C
). If, given commits c1
and c2
, the path path1
has disappeared from c1
and path2
has appeared in c2
, that's a "rename candidate". If the file contents of path2
are sufficiently similar to those of path1
, the file must have been renamed (and possibly modified as well, if -M
is less than 100%
).
To decide that a rename was a "directory rename" you'd need to add code of the form:
- every file in
dir1
disappeared (including untracked and ignored files) - no file appeared in
dir2
before (including untracked and ignored files) - given the dynamically-detected renames, "enough" files with name
dir1
were renamed so thatdir1
becamedir2
in the path, while the rest of the name remained the same
to decide that dir1
was renamed to dir2
. (The "enough" in the last point allows a few files to have been renamed outside of the new dir2
.)
The really sticky point here is the two parenthentical bits, "including untracked and ignored files". Clearly git can't tell you about the history of such files. (One could of course just assume that no such files exist, perhaps under control of an option flag.) I'm not sure if this was a factor in deciding not to write that bit of algorithm; but as far as I know, it's not in there.