Re: Mercurial vs. git

[olafBuddenhagen]

Hi,

On Wed, Oct 28, 2009 at 08:03:26PM +0100, Arne Babenhauserheide wrote:
> Am Sonntag, 25. Oktober 2009 10:54:44 schrieb olafBuddenhagen@gmx.net:

> > > 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!
> 
> That's not really a specific task to me, but basic operation... 

Well, it was you who mentioned it as something not everyone needs to
know... :-)

Of course merging branches is a basic operation. My point is that any
additional stuff necessary to efficiently manage a lot of branches --
assuming there is any -- follows directly from the Git fundamentals;
there isn't really anything new you need to learn to be efficient in
this specific situation, once you have a good understanding of the
fundamental concepts. And the same is true for most other use cases too.

> > 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.
> 
> Then lets state it more precisely: 
> 
> "The time spent using it" has to be changed to "the time overhead
> created by the time spent in the version tracking part of the work". 
[...]

You are complicating it unnecessarily. If you really want to compare
absolute times, just compare the total time spent on the work --
including both actual programming and all the versioning stuff.

However, even that doesn't tell the whole truth. If I can do everything
I want with the version control system, without having to workaround
unfitting models; without having to fear screwing up; and without having
to learn new commands/options: aside from direct time savings, this has
another very important effect: it reduces frustration. And that's rather
hard to measure in terms of time...

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

> In Mercurial people routinely jump back and forth, use feature clones
> and much more, because it is really easy and fast - you'll notice,
> that it's in the basic workflows for which you don't need any
> extensions (the ones in the guide). 

Yes, this is stuff that everyone *has* to learn at least some basic
receipes for, to get on at all -- there is no difference between Git and
Mercurial there, except that it's probably somewhat easier to get such
superficial knowledge in Mercurial. (For people coming from SVN at least
-- I'm still not convinced that it's siginficantly harder for people
without such a predisposition...)

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.

(As I said before, I wouldn't necessarily recommend Git for
non-programmers.)

-antrik-