This means that you should not rename or copy a file and modify it in the same commit, because that makes git's rename inference harder. Similarly if you rename a directory, don't modify any of its contents (including renames and permissions changes) in the same commit.
This seems particularly perverse given the fact that renames often want to be accompanied by changes in the renamed files. For instance, move source files about, update all the internal pathnames by which they refer to each other. Rename a program, change the name in its help and error messages. And so on.
Of course you could do those in a pair of consecutive commits, but isn't it obviously more useful to be able to come back later and find a single commit in which The Great Rename took place atomically? It makes version-control archaeology easier, since you don't have to augment your mental model of the actual software development with a mental model of things that had to be done a certain way due to VCS limitations; and it also makes it much easier to extract a diff or changeset description to send to someone else.
no subject
Date: 2009-04-24 08:38 (UTC)This seems particularly perverse given the fact that renames often want to be accompanied by changes in the renamed files. For instance, move source files about, update all the internal pathnames by which they refer to each other. Rename a program, change the name in its help and error messages. And so on.
Of course you could do those in a pair of consecutive commits, but isn't it obviously more useful to be able to come back later and find a single commit in which The Great Rename took place atomically? It makes version-control archaeology easier, since you don't have to augment your mental model of the actual software development with a mental model of things that had to be done a certain way due to VCS limitations; and it also makes it much easier to extract a diff or changeset description to send to someone else.