Re: Mercurial vs. git

[olafBuddenhagen]

Hi,

On Wed, Nov 04, 2009 at 10:06:02PM +0100, Arne Babenhauserheide wrote:
> Am Sonntag, 1. November 2009 09:53:44 schrieb olafBuddenhagen@gmx.net:

> And here's exactly where I see a problem: You need the good
> understanding for beginning - but once the thought "this is hard" has
> set its root in the mind, it's damn hard to rip out again (which in
> turn hampers further learning).

Well, in my case this is not a problem at all: if I learn something that
I expect to be using in a serious manner, I usally sit down and read
most of the documentation *before I even start using it*. I want to do
it right from the beginnig.

I can see though how Git can be problematic for people who try to learn
it bit by bit...

> So it's most efficient to make the entry very easy for people. 

Well, it's a tradeoff. I am myself an advocate of making entry as easy
as possible (see
http://tri-ceps.blogspot.com/2005/08/design-by-bulldozer.html for
example, and also some of my post to the hurd lists; most recently
regarding handling of new components...) -- but not at the expense of
making it less efficient for experienced users. I think that often it is
possible to do both; but in most of the software available today, we
don't have that -- it's either one or the other. (This is something I
yet need to write about.)

So most of the time, we have to choose between these goals. And given
this choice, I usually take the one that requires more investment up
front, but is more efficient once there. (In almost all cases where I
tried the other, I soon regretted it.)

This is why I prefer Git. I'm not sure whether it is possible at all to
create a version control system that is as efficient as Git for
experienced users, and yet offers easier entry; but in either case, I am
pretty sure that such a thing doesn't exist today. So we have to make a
choice -- and for anyone doing serious programming, Git is IMHO the
better one.

> > > But that really defeats everything you write later about efficient
> > > workflows.
> > 
> > No, it doesn't. I was talking about how Git allows being very
> > efficient, once you get a good understanding of the fundamentals.
> > The fact that most people don't bother, doesn't change this at all
> > :-)
> 
> But for most users it invalidates the advantages you write about. 

Perhaps I should be more explicit: I couldn't care less :-) If people
try to get away without learning it properly from the beginning, it's
their own fault. Sorry if you happen to be one of them :-P

> > You can only make good use of Git's potential if you bother to get
> > past that, and actually learn the universal underlying concepts. The
> > fact that you can do pretty much anything, and without having to
> > learn additional features, once you have learned these concepts,
> > makes Git more efficient for programmers IMHO -- *if* they are
> > willing to learn.
> 
> My question here is, how often you need these advanced workflows

Quite often actually.

I was in fact pretty reluctant to learn Git -- I was always able to do
my work *even with CVS*; and while it was very annoying sometimes, I
didn't believe a better system would really make that much of a
difference. I was fully expecting that I will need several days to learn
Git properly, and I didn't really believe that I would ever make that up
in efficiency...

But when I was actually learning it, I was really impressed -- I saw
that it is much nicer than I expected. And when I actually started using
it, I very soon began to love it dearly. Even though the project I used
it mostly for so far (my KGI port) has extremely low requirements -- one
branch, no interaction with others -- I get into situations all the time
where I think, "it's *so* nice that I can take these shortcuts thanks to
Git".

This is very similar indeed to how the extensible system environment of
the Hurd can make things easier: it's not really possible to explain --
you can only understand it once you are on the other side. When trying
to explain how the Hurd offers more possibilities, people can't
understand how these could be useful. They use a system with a given set
of functionaliy, and somehow manage to get their stuff done within these
constraints. (Or refrain from doing it alltogether, if it's too
complicated.) They do not realize how these things could be done much
easier in a system with less constraints.

> - and how easy it is to teach them to others when you want to
> interact. 

Must be talking past each other here... This is about *me* doing *my*
work efficiently in *my* repository. How efficiently or inefficiently
others deal with the stuff I publish, has little effect on my own
efficiency.

> > (As I said before, I wouldn't necessarily recommend Git for
> > non-programmers.)
> 
> (...while I want a tool which I can use together with artists and
> writers - and DAUs: "dümmste anzunehmende user" == "dumbest expectable
> user" - but that is still efficient to use for me, so we have quite
> different requirements - which explains many of our different
> opinions, I think :) ). 

My opinion is that there is no "one size fits all" here.

Admittedly, this makes it a bit hard to find a good compromise in
projects that involve both serious programming and non-programming
content in the same repository...

-antrik-