Re: Mercurial vs. git

[Arne Babenhauserheide]

Hi Olaf, 

Am Samstag, 24. Oktober 2009 06:08:49 schrieb olafBuddenhagen@gmx.net:
> Depends on how you count. Of course you can manage to live somehow
> knowing only part of the features of the VCS; and I'm willing to believe
> that getting to this point is indeed somewhat easier with Mercurial.
> However, to use the system *efficiently*, you have to fully understand
> it

Yay, reviving the thread! ;) 

It depends on your measure of efficiency - and on what you need to do. 

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. 

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

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. The second is mostly just calling "hg help <command>" and looking at 
the options. 

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. 

To illustrate that: 
- http://hg-scm.org/workflow-guide

especially this part: 
- http://hg-scm.org/workflow-guide#basic_summary

That's a guide (I wrote) which leads you through learning Mercurial with 
workflows (from simple to complex whiele the complex workflows build on the 
previous simple ones). It doesn't explain any internals, but it completely 
suffices to learn to use Mercurial efficiently. 

It also shows how much you can do with Mercurial without activating any 
extensions -> you only have to learn the extensions you actually use, which 
saves a lot of time. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- 
Unpolitisch sein
heißt politisch sein, 
ohne es zu merken. 
- Arne (http://draketo.de)
--- --- --- --- --- --- --- --- ---

signature.asc
Description: This is a digitally signed message part.