Date: 2009-04-24 08:38 (UTC)
simont: A picture of me in 2016 (Default)
From: [personal profile] simont
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.
This account has disabled anonymous posting.
(will be screened if not on Access List)
(will be screened if not on Access List)
If you don't have an account you can create one now.
HTML doesn't work in the subject.
More info about formatting

If you are unable to use this captcha for any reason, please contact us by email at support@dreamwidth.org

July 2025

S M T W T F S
  1 2345
6789101112
13141516171819
20212223242526
2728293031  

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated 2025-07-08 17:13
Powered by Dreamwidth Studios