> From: "Philip Oakley" <[email protected]> > > > 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 others? Dale --
