LWN: Comments on "Git approaches 1.0"

Git developers aren't kernel developers?

Wol — 2005-08-04T07:24:50+00:00

A large and active development community coalesced around git in short order; interestingly, relatively few of the core git developers were significant kernel contributors.

That shouldn't actually be a surprise. Like many people, I like to follow kernel development (but, as I don't run linux much :-( I don't really contribute).

But what I'm really involved in, and would be more involved in if I could find the time, is database development. It's what I do professionally (use and program databases) and, inasmuch as I do Free Software development, it's database engine stuff.

Cheers,
Wol

Renames

karath — 2005-08-02T15:58:45+00:00

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,
Charles

Renames

bronson — 2005-08-01T17:17:42+00:00

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!

And don't forget Mercurial

corbet — 2005-07-28T15:10:17+00:00

It's on my list. I went to Matt's session at OLS, and I'm meaning to play with it some, when I get a chance...

Renames

vmole — 2005-07-28T15:07:29+00:00

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.

And don't forget Mercurial

bos — 2005-07-28T15:00:32+00:00

Jonathan, perhaps you could do an article on Mercurial, since it's the other major distributed revision control system to have appeared since BK became unavailable to non-paying-customers.

It doesn't have the same size of galloping horde behind it that git does, but it has a devoted following in the kernel development community, and is seeing intense interest outside that sphere.

But I'm biased, because I work on it a lot :-)

http://www.selenic.com/mercurial
http://www.serpentine.com/mercurial