VCS comparison table

[Andreas Ericsson]

David Rientjes wrote:
> On Wed, 25 Oct 2006, Jeff King wrote:
> 
>>> This all became very obvious when the tutorials came out on "how to use 
>>> git in 20 commands or less" effectively.  These tutorials shouldn't need 
>>> to exist with an information manager that started as a quick, efficient, 
>>> and _simple_ project.  You're treating git development in the same light 
>> Sorry, I don't see how this is related to the programming language _at
>> all_. Are you arguing that the interface of git should be simplified so
>> that such tutorials aren't necessary? If so, then please elaborate, as
>> I'm sure many here would like to hear proposals for improvements. If
>> you're arguing that git now has too many features, then which features
>> do you consider extraneous?
>>
> 
> It's not, it's related to the original vision of git which was meant for 
> efficiency and simplicity.

Compared to todays version, original git was neither efficient nor 
simple. Unless you mean "some random version along the way where git had 
everything *I* need and not the useless cruft that other people use", in 
which case it's simply a very egotistical view of things.

>  A year ago it was very easy to pick up the 
> package and start using it effectively within a couple hours.   Keep in
> mind that this was without tutorials, it was just reading man pages.  
> Today it would be very difficult to know what the essential commands are 
> and how to use them simply to get the job done, unless you use the 
> tutorials.

Have you tried "git --help"? It shows the most common commands and a 
short description of what they do. It's a very good pointer to which 
man-pages you need to read, and I imagine this would actually be one of 
the very first commands that new git users try. If they don't but just 
expect things to work according to some premade mental model they have 
of scm's, I'd say they'd be screwed no matter which software they tried.


>  This _inherently_ goes against the approach of trying to 
> provide something that is simple to the developer.
> 
> Revision control is something that should exist in the background that 
> does it's simple job very efficiently.  Unfortunately git has tried to 
> move its presence into the foreground and requiring developers to spend 
> more time on learning the system.
> 

No it hasn't. The ten or so commands that Linus first introduced when 
announcing git still work pretty much the same. Nobody in their right 
mind would ever claim that those ten commands made up anything that even 
remotely resembled a complete scm, but they were something to build on 
by anyone who wanted to extend it. So far, ~220 people have wanted to 
extend it in ways that others thought useful, because their patches are 
apparently in the git tree.

> Have you never tried to show other people git without giving them a 
> tutorial on the most common uses?  Try it and you'll see the confusion.  
> That _specifically_ illustrates the ever-increasing lack of simplicity 
> that git has acquired.
> 

Well, my head hurt when I tried to learn CVS without a tutorial, and 
mercurial and darcs and svn as well. I didn't pick up the functionality 
of the 'ls' command completely without reading the man-page for it. If 
you want something that works for everyone without having to read any 
documentation what so ever, buy Lego, cause computers ain't for you, my 
friend.

>> I don't agree with this. There are tons of enhancements that I find
>> useful (e.g., '...' rev syntax, rebasing with 3-way merge, etc) that I
>> think other developers ARE using. There are scalability and performance
>> improvements. And there are new things on the way (Junio's pickaxe work)
>> that will hopefully make git even more useful than it already is.
>>
> 
> There are _not_ scalability improvements.  There may be some slight 
> performance improvements, but definitely not scalability.  If you have 
> ever tried to use git to manage terabytes of data, you will see this 
> becomes very clear.  And "rebasing with 3-way merge" is not something 
> often used in industry anyway if you've followed the more common models 
> for revision control within large companies with thousands of engineers.  
> Typically they all work off mainline.
> 

Actually, I don't see why git shouldn't be perfectly capable of handling 
a repo containing several terabytes of data, provided you don't expect 
it to turn up the full history for the project in a couple of seconds 
and you don't actually *change* that amount of data in each revision. If 
you want a vcs that handles that amount with any kind of speed, I think 
you'll find rsync and raw rvs a suitable solution.

On the other hand, you fellas at google don't really use git to store 
the data from the search database, do you? I mean, it's written for 
source control management. People that tried to keep their mboxes in git 
failed miserably, because large files that constantly change just 
doesn't work well with git.

>> If you don't think recent git versions are worthwhile, then why don't
>> you run an old version? You can even use git to cherry-pick patches onto
>> your personal branch.
>>
> 
> I do.  And that's why I would recommend to any serious developer to use 
> 1.2.4; this same version that I used for kernel development at Google.
> 
>> Where?
>>
> 
> Few months back here on the mailing list.  When I tried cleaning up even 
> one program, I got the response back from the original author "why fix a 
> non-problem?" because his argument was that since it worked the code 
> doesn't matter.
> 
> 	http://marc.theaimsgroup.com/?l=git&m=115589472706036
> 
> And that is simply one thread of larger conversations that have taken 
> place off-list and aren't archived.
> 

First off, the code got changed as per Junio's desires. He's the 
maintainer and gets to choose about coding style and readability vs 
microoptimizations.

Second, why keep discussions about git development off-list?

Third, if you still have issues with it, why not provide a patch and see 
if Junio accepts it? Cleaner and faster code will, in my experience, 
always get accepted. Code that is cleaner from one devs point of view 
but doesn't actually provide any other benefits will be dropped to the 
floor, and rightly so.


>> I don't agree, but since you haven't provided anything specific enough
>> to discuss, there's not much to say.
>>
> 
> If there's a question about some of the sloppiness in the git source code 
> as it stands today, that's a much bigger issue than the sloppiness.  My 
> advice would be to pick up a copy of K&R's 2nd edition C programming 
> language book, read it, and then take a tour of the source code.
> 

The first sentence doesn't make sense. The second one is just rude, and 
formed by your own opinion on how code should be written. But again, 
submit patches and see if Junio accepts them. If he doesn't, and you 
really, really *really* can't stand the changes he and the rest of the 
git community wants in, fork your own version and hack away til your 
heart's content. Git makes it easy for you, whichever version you use.

>> Can you name one customization that you would like to perform now that
>> you feel can't be easily done (and presumably that would have been
>> easier in the past)?
>>
> 
> Yes, those mentioned above.
> 

Which ones? The git-mv changes you submitted were applied (although in a 
different shape), so there must be other ones. Rewriting C builtins as 
shell-scripts is not really an option, because portability and 
performance *does* matter.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231