VCS comparison table

David Rientjes rientjes at
Wed Oct 25 18:21:42 BST 2006

On Wed, 25 Oct 2006, Jeff King wrote:

> Yes, it's true that some operations might be easier to play with in the
> shell. However, does it actually come up that you want to modify
> existing git programs? The more common usage seems to be gluing the
> plumbing together in interesting ways, and that is still very much
> supported.

Yes, it does.  I'll give you an example from six months ago: there was a 
need for the group that I work with to support a faster type of hashing 
function for whatever reason.  This would have been simple with previous 
versions of git, but if you've ever looked at the SHA1 code in git, you'll 
realize that you're probably better off never trying to touch it.  There 
is absolutely _no_ abstraction of it at all and the code is so deeply 
coupled in the source that abstracting it away is a pain.

Likewise, there is always room for personal or organizational tweaks on 
the part of the developer.  Things like distributed pulling and 
merging should actually be pretty simple to implement if the complexity 
wasn't so high in the merge-* family.  This is something I implemented 
after an enormous headache because we were dealing with very large 
projects: yes, larger than the Linux kernel.  And this is _exactly_ where 
piping would help; we have implementations of distributed grep over very 
large datasets (on the order of terabytes).

> You can do the same thing in C. In fact, look at how similar
> git-whatchanged, git-log, and git-diff are.

No you can't.  Making a one line addition, commenting out a line, or 
changing a simple flag in a shell script is much easier.  And like I 
already said, you can save multiple versions for your common use if you 
work on a specific project much of the time and change how it operates 
depending on the needs of that one project so you never need to do it 
again or you can _distribute_ that shell file to your colleagues so that 
everybody is doing their work via the same method.  This makes it so you 
can just say "type X, then type Y, then type Z" and everybody is operating 
together without training them on how to use git.

> > 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.  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.  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.

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.

> 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.

> 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.

And that is simply one thread of larger conversations that have taken 
place off-list and aren't archived.

> 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.

> 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.


More information about the bazaar mailing list