Why we didn't migrate to Mercurial (long)

[Ciprian Dorin Craciun]

    Disclaimer for biased opinion: I'm a Git user "trapped" / "forced"
in a Mercurial world... :) (Without HG-GIT I would go nuts...)


On Fri, Oct 5, 2012 at 8:44 AM, 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.

    Actually the Git workflow of "experimenting" is not to:
~~~~
git checkout <<some-commit>>
# now you're left in a detached head mode
...
git checkout -b <<feture-x>>
git commit
~~~~ but instead
git checkout -b <<just-put-a-name>> [<<some-reference>>]
# any name it will do, even `test-1`, as you can rename it later
...
git commit
# if you've got a better name for your experiment
git branch -m <<just-put-a-name>> <<feature-x>>
~~~~

    But the real advantage that Git has, and Mercurial doesn't --
which DRIVES ME NUTS -- is that I can "drop" my experiment:
~~~~
git checkout <<some-commit-for-a-fresh-start>>
git branch -D <<my-failed-experiment-i-want-it-gone>>
~~~~

    How do I achieve this in Mercurial?
    * remove the repo, clone another one but only up to my first messy
commit; (don't forget the other named branches)
    * or use some plugin that is always disabled by default and
involves multiple commands;
    * or PLEASE tell me a simpler way?


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

    Exactly. I wouldn't use Git if it didn't have this yeature.


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

    Again exactly... When choosing the Mercurial workflow for our
project I've ended up with:
    * use named branches **only** for releases and maintenance on
those releases;
    * use `default` for **all** development, and use bookmarks for features;
    * and rule (1) of "don't screw up your changeset, as if I need to
strip it from the official repo you'll be sorry"... :)
    * and rule (2) of "don't push experimental changesets into the
official repo or you'll suffer the same consequences as for rule
(1)"...
    * and rule (3) of "when the feature is ready, and you're shore you
don't need to back out, just push it to the official repo";
    * and optionally rule (4) of "maybe better push it to your clone,
and the liutenant of the official repo will pull it";

    Actually I've applied a Git workflow to Mercurial... (Because it
is the sanest approach I could thing about...)

    How would this have looked in Git:
    * the official repo is fast forward only; (no history rewriting;)
    * just name your experiment whatever you want and push it;
    * is the experiment a failure: just delete the branch, push it and
your traces are lost;
    * it is advisable to have a "private" repo for each user, but it's
not mandatory;


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

    Yup.

    Ciprian.