> From: "Philip Oakley" <philipoak...@iee.org>
> > OK, so it seems that when you move files around, and then tell git to
> > notice that, git will automagically figure out what the moves were.
> > The O'Reilly book wasn't clear on that. (Nor did it explain how git
> > can distinguish a move from file that just happens to have the same
> > contents.)
> Actually git does not even attempt to record the movements themselves.
> There is a strongly worded post by Linus Torvalds all about why he
> *believes* it is the Right Thing (tm) to do.
> The key being that git is a *content* tracker, not a file tracker, and
> if you commit often the changes are small, so it is easy to infer where
> the changes came from and went to.
Let me see if I understand this: Git only connects the "before" and
"after" locations of a file by the fact that they have the same (or
very similar) contents.
How, then, do merges handle this information? If the "delta" is that
./a/123 was moved into ./b/456, does the merging process understand
that, and move the same file in the destination directory? Or does it
only do so if ./a/123 in the destination directory is similar enough
to ./a/123 in the delta?
Similarly, if the delta is a particular change in file A, if in the
destination directory there is a very similar file B, will merging
change B? What if there are multiple files in the destination
directory with similar contents; might they all be changed?
If there are multiple files in a tree with identical contents (say,
all zero-length), does Git confuse changes in one with changes in the