VCS comparison table
rientjes at cs.washington.edu
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
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.
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
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