| |||||||||||||
RenamesRenamesPosted Jul 28, 2005 15:07 UTC (Thu) by vmole (guest, #111)Parent article: Git approaches 1.0
One of the harder problems in many SCM systems - handling the renaming of files - requires no special care with git. That's because git completely ignores the problem. Renaming "foo" to "bar" is treated exactly the same as deleting "foo" and then creating "bar". By this definition cvs handles renames just fine, too. Linus handwaves this problem by saying you can compare content of "foo" and "bar" and guess that the transition was a rename. I personally don't want my SCM to be "guessing" about what has happened. Which is not to diss git. It does what Linus wants it to do, and does it very quickly. It's an impressive piece of work, and especially so considering the timeframe. But it's not suitable for every development project or style.
(Log in to post comments)
Renames Posted Aug 1, 2005 17:17 UTC (Mon) by bronson (subscriber, #4806) [Link] It's a little more subtle... During development, files are always being created and destroyed and great swaths of code moved between them. The filename is just a temporary label. It's the content that is key.
Git will tell you "File A in tree 1 is 78% the same as File B in tree 2." The developer then knows that file B derives heavily from file A. One day git will also be able to tell you that "File C is 95% the same as parts of file A, and file D is 98% the same as parts of file A." This makes it pretty clear that file A was split into files C and D. Git just follows the content, no more, no less.
"Sure," you say, "svn mv and cp can show this and it's much easier to use!" (or Arx or insert favorite CMS here) So let's consider more real-world problems. What if you scatter the functions in file A across 5 different files, 3 of which already exist. Consider, for instance, the great USB reorg. Git still happily tells you exactly what happened, whereas file-based CMSes fall flat or, at the very least, need a colossal amount of hand-holding. Git encourages broad refactoring. By locking the filename to particular content, other CMSes tend to discourage it.
Git tells you _exactly_ what happened. Where did you get the idea that it guesses?
"But it's not suitable for every development project or style."
I doubt anybody would disagree with this!
Renames Posted Aug 2, 2005 15:58 UTC (Tue) by karath (subscriber, #19025) [Link] I am interested to know how GIT does the fragment tracking as described in the previous message. I have followed the GIT mailing list closely and have seen a hint from Linus that fragment tracking is what he sees a need for in the future.
However, my understanding is that, while GIT is layered on a content addressable "filesystem", the content addressing system used is the SHA1 sum of the entire content of the file. So, without specific tools that seach for fragment matches in different files, I cannot not see how GIT does fragment tracking.
BTW, GIT now has commands to explicitly track renames.
regards,
|
|||||||||||||