bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mercurial vs. git


From: Arne Babenhauserheide
Subject: Re: Mercurial vs. git
Date: Wed, 4 Nov 2009 22:06:02 +0100
User-agent: KMail/1.12.2 (Linux/2.6.30-gentoo-r5; KDE/4.3.2; x86_64; ; )

Am Sonntag, 1. November 2009 09:53:44 schrieb olafBuddenhagen@gmx.net:
> > > 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... :-)

damn... 

*scans for inconsistency in brain*

I assume it's because it isn't really basic for me to do with git, but it is 
trivial for me to do with Mercurial... 

(In git I still need to read my self.written little "news-contributing"-guide 
in the wiki everytime I want to merge a branch...)
 
> 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.

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). So 
it's most efficient to make the entry very easy for people. 

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

Jupp, that fits it. 

> another very important effect: it reduces frustration. And that's rather
> hard to measure in terms of time...

But that's were Git really screwed up in my case, while Mercurial excelled... 

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

> 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 - and how easy 
it is to teach them to others when you want to interact. 

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

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
Ein Mann wird auf der Straße mit einem Messer bedroht. 
Zwei Polizisten sind sofort da und halten ein Transparent davor. 

        "Illegale Szene. Niemand darf das sehen."

Der Mann wird ausgeraubt, erstochen und verblutet, 
denn die Polizisten haben beide Hände voll zu tun. 

Willkommen in Deutschland. Zensur ist schön. 
                      (http://draketo.de)
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]