Re: Mercurial vs. git

[olafBuddenhagen]

Hi,

On Sat, Oct 24, 2009 at 01:57:22PM +0200, Arne Babenhauserheide wrote:
> Am Samstag, 24. Oktober 2009 06:08:49 schrieb olafBuddenhagen@gmx.net:

> Yay, reviving the thread! ;) 

Sorry, couldn't resist... :-)

> If you use the system for tracking your coding and occassionally
> merging with changes from others, then you don't have to fully
> understand it, since the tracking of changes can be done quite well
> without full understanding. 
> 
> If you don't have to integrate hundreds of branches, then there's no
> merit in learning how to do that efficiently - so it isn't efficient
> to have to learn background for that before being able to use the
> system efficiently for other stuff. 

The point is that there is hardly anything you need to learn for
specific tasks like integrating many branches -- once you understand the
basics, most specific tasks become trivial!

And programming is not systematic enough that you can avoid doing all
kinds of specific stuff now and then. I claim that *every* regular
programmer can profit considerably from being really proficient with the
VCS.

It's different for a wiki of course -- here indeed the requirements for
non-trivial operations are so rare, that learning efficient VCS usage is
not likely to pay off...

> For me the measure of efficiency is: * Time for initial learning until
> I can use it, plus * Time I spend relearning stuff I forget (a major
> factor with git for me), plus * Time to learn the new stuff I need and
> for optimizing, plus * Time I actually spend using it. 
> 
> That calculated for different systems to be able to compare them. 
> 
> With git the first and second are quite high (for me) for basic
> features like branching and merging (that's why I wrote a guide on
> merging the news - I use that guide myself when I prepare the next
> news). 
> 
> The optimizing part only makes sense, when it saves netto time -> when
> I use the system so much that the time I save per usage ??? the number
> of times I use it is higher than the time spent on optimizing it.
> Since most developers firstly write code and only secondly manage
> history, optimizing a git workflow often doesn't make that much sense
> (simlarly it doesn't make must sense for most people to write a
> Mercurial extension for their individual workflow). 

You can't measure the efficiency of VCS usage by "the time spent using
it". That just doesn't reflect reality. "Managing history", and other
VCS usage, is not a separate task -- using the VCS is part of the
programming workflow. Efficient VCS usage is about being able to perform
my *programming* work in the most efficient manner.

> With Mercurial on the other hand, the first is very short and the
> third also stays short for the stuff most people need. For example I
> never had to work with Mercurial Queues (doing patch reworking), so I
> never had to learn how to use them.

It's not about what you *have* to do, but about what you *can* do. As I
already said at the setout, it is perfectly possible to perform all
tasks with only a handful of fixed workflows, and with VCS knowlegde
limited only to these few workflows. (In fact, even most git users seem
to work that way -- which is a very sad situation indeed :-( )

But that's not efficient. Programming is not a linear or systematic
task. When programming, I write a bit of code; while at it, I discover
something else I can improve or need to fix; or I realize that I have to
change something else first in order to do the change I intended; or I
realize that the changes are more complex, and I have to split them up;
or I realize that I have to go back and change the approach; or I
realize that something I changed in the past didn't make sense after
all; or I decide to work on an entirely different thing for now; or I
realize that the change I am working on makes more sense in a different
branch; or I realize that I forgot to commit something, or commited too
much; or I want to try things out, later abandoning them again, or
include them in some branch; and so on.

These things happen *all the time*; they are part of the normal
programming process. All of them require using the VCS in some
particular way -- and only with a VCS that allows me to do exactly what
I want without ceremony, I can work efficiently. If I have to work
around, because the thing I want to do doesn't fit the model of the
system; or if I have to learn new functionality to be able to do the
thing I want: that's not efficient.

(This is where Git scores: the model is so flexible that very few things
do not fit in it; and the fundamental concepts so universal, that once I
internalized those concepts, I can do almost anything I want -- no
matter how unusual -- without needing to learn new things.)

Let's take changing history as an example, as this seems to be a major
point of contention. You can muse about the meaning of history etc. as
much as you like -- but I simply don't buy the (implicit) claim that
there are many people and projects who really don't give a damn about
how the history looks, when I apply changes back and forth five times
while changing my mind, or about loads of micro-commits I do while
working on more complex changes. Such a history not only is really ugly
to look at, but also makes it virtually impossible to review changes,
and totally breaks bisecting.

The truth is that no matter what the policy is regarding history: if I
can't easily change my mind or do temporary commits without making a
mess, this *will* create pressure to avoid doing these things, and thus
hamper my productivity: it means I have to try to make up my mind up
front, and stick to my decisions even if they prove suboptimal, rather
than using the much more efficient approach of trying things out and
adapting as I go along. (The only alternative being to refrain from doing
any commits at all until I am confident that the decisions were right,
resulting in other problems.) It also means I can't use the VCS to track
temporary steps while working on larger changes, i.e. I can't make use
of the VCS to ease my work.

In short: creating temporary commits that are not meant to be part of
the permanent public history of a project, is a natural desire of every
(normal) developer; and using a VCS that doesn't encourage this, or a
VCS that I don't understand well enough to do this with ease and
confidence, considerably hampers my efficiency as a developer.

> And since git isn't noticeably faster for most common operations, it
> simply isn't more efficient (for people who don't need complicated
> workflows). For me its overhead for learning and relearning its basics
> is too high (though the relearning grows much smaller over time, if
> you use it all the time. 

Yeah, if the Hurd wiki is the only project using Git you are involved
with, it might indeed not be worth it to learn it properly.

But for anyone doing serious coding, the situation is very different.

-antrik-