Why we didn't migrate to Mercurial (long)
Victor Suba
vosuba at gmail.com
Fri Oct 5 06:00:39 UTC 2012
Note that the question "Why should git branches be the role model?" is kind
of redundant,
they have already been modeled since around Mercurial 2.3 :P.
On Thu, Oct 4, 2012 at 10:44 PM, Victor Suba <vosuba at gmail.com> wrote:
>
> $ git checkout -b eyelet <some_revision>
>> <hack hack>
>> $ git commit -a
>> $ git push
>> Everything up-to-date
>> WTF!? You probably know the rest: create a remote, add a tracking
>> branch, bind it with your newly created branch, etc. That doesn't
>> encourage me to branch much.
>
>
> Isn't that just lack of familiarity? For start usually we don't need to
> publish our feature
> branches, but when we do there's a simple command to publish and set up
> tracking
> at the same time.
>
> $ git push -b origin eyelet (push eyelet branch to "origin" and track
> it)
>
> The point is: why should git branching be the role model? Who decided
>> that? The fact that Mercurial has a simpler interface does not mean is
>> less capable. And, as I already mentined, that's just unfair.
>>
>
> Nobody's saying that the simpler interface makes Mercurial less capable.
> It's really
> not about the look and feel, but about the underlying branch mechanisms -
> and comparing
> those can be compared pretty objectively.
>
> The basic Hg branch. which is named, can be merged upstream as long as it
> has just 1 head.
> Hg will handle syncing with other repos nicely since there's a 1 head to 1
> head binding.
>
> You can create lightweight branches in Hg by just updating to some
> revision and starting
> to commit. Simple. Just 2 issues:
> 1) you can't really work with multiple heads on the same 'real' branch
> when you have to sync
> with other repos because you're missing that 1 to 1 head binding. Hg
> will complain if you try.
> 2) you need some kind of tag to know what each head was supposed to be
> about.
>
> Bookmarks were added, which basically satisfied issue #2, but not
> #1, because
> a) bookmarks were 2nd hand branches and Hg would still complain about
> multiple heads
> per 'real' Hg branch.
> b) syncing bookmarks had only rudimentary capabilities for merging, so
> you could publish
> bookmarks but you couldn't collaborate well using bookmarks. You need to
> use heavyweight
> threads to collaborate.
>
> So why should git branches be the role model? Perhaps because they
> already got all this
> working well with just one kind of branch. Git's branches are simple.
> They are just bookmarks
> designed with syncing in mind - they're not 2nd hand citizens; they're not
> limited in what you do
> with them compared to some other heavier 1st hand branch.
>
> That's it - no long essay needed to describe Git really. Unfortunately
> many long essays have been
> written to try and get better light weight branches into Hg.
>
> On the other hand, why should Hg branches be the role model? Is it better
> to have 2 types of
> branches? Is it better to have heavy branches as well as light branches?
>
> Hg looks simple, but that's just the command line syntax. If one were to
> describe the now core
> features of git and hg, I'm pretty sure hg's has become more complicated.
>
> -Vic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20121004/4cd5e074/attachment-0002.html>
More information about the Mercurial
mailing list