
No, mercurial branches are still not better than git ones - vgnet
http://felipec.wordpress.com/2012/05/26/no-mercurial-branches-are-still-not-better-than-git-ones-response-to-jhws-more-on-mercurial-vs-git-with-graphs/
======
viraptor
Well, that's one biased post.

In "bookmarks are not enough", the author claims that that the commits just
stay there after deleting the bookmark - the horror! Actually, the same thing
happens in git. Commit unreachable via names will stay around until you run
garbage collection. You can still see them in reflog.

"Anonymous heads" - yes, that exactly why `hg push` warns you. Exactly the
same reason rebase warns you that it's destructive and pull rebase isn't the
default. So you don't make a mess by accident. If you want to see what's
available in the remote repository, like after `git fetch`, you can see the
new commits via `hg incoming`.

I can't agree with "Nothing is lost" either - the tree he presents is trivial.
Give it a go on a repository with 10+ topic branches which are re-synched to
trunk a number of times and with more than 2 commits. Suddenly getting
everything labelled with branch names is much more useful.

I'm not against one system or another, but having a fair explanation of both
systems would be nicer than a blog saying pretty much "it's different than
git, therefore it's bad". In the end it's down to personal preferences. Some
people find "branch labels" more comfortable to work with, some prefer "branch
bookmarks". That's it. Yet every once it a while we get a long "but this is so
much worse than git!" explanation. Great, I'll keep using hg because I like it
better, thank you very much.

~~~
kerouakas
The most sensible comment I have seen on HN for quite a while. Thank you!

------
kevingadd
This goes a long way towards explaining some of the things I don't like about
Mercurial but haven't ever fully understood. I didn't even realize the git and
mercurial concepts of branches were different!

~~~
angerman
me neither, but now I understand why some discourage the concept of creating
many tiny branches in hg. [you can't delete them -- i still find this hard to
believe]

~~~
anthonyb
I've never really understood the way that you can rewrite history in Git. It
seems really odd to me - completely counter to the idea of having a repository
in the first place.

From the article:

    
    
        That is why git branches are so useful; you can do
        absolutely anything that you want with them. When you 
        are done with the ‘quick-fix’ branch, you can just
        remove it, and nobody has to know it existed
    

That actually sounds quite horrible. What if you make a mistake and remove a
branch that you _didn't_ want to remove? What if you remove the branch and
nobody has any idea where change 'x' came from or why?

~~~
vibrunazo
You're removing the branch, not the whole commit. They can still see where the
change came from by looking at the commit history and message. But they don't
need to know how you locally organized your own self when you did it.

~~~
tbatterii
mercurial patch queues are for that kind of workflow.

~~~
regularfry
Can you have more than one patch queue going at once?

~~~
tbatterii
I could. And I have. And I do. But I know what I'm doing with them :)

My point was that patch queues are more for the kind of workflow that might be
experimental in nature, that you might not want to land on the mainline for a
while (if ever).

~~~
regularfry
How? I thought you could only have one patch series going at a time.

~~~
tbatterii
maybe I am misunderstanding your question. Can you give me an example?

~~~
regularfry
With git, you can have more than one experimental branch going at once, with
more than one commit in each, and switch between them at will. I don't know
how to do that with mercurial. It might be possible with a version controlled
queue, but if it is I don't know the cli calls to make it happen.

Here's a hypothetical git workflow:

    
    
        git checkout -b experiment_1
        git commit -m "A"
        git commit -m "B"
        git checkout master
        git checkout -b experiment_2
        git commit -m "C"
        git commit -m "D"
    

At this point, I've got one experiment going with A and B, and another with C
and D, both branching from the same master commit. My understanding of mq is
that I could have either experiment_1 or experiment_2, but not both.
Admittedly it's a situation which doesn't come up often, but it's _just_ often
enough that I'd be intrigued if hg could do the same.

~~~
tbatterii
I do that by pushing, popping and reordering patches.

For example right now in my queue I have a patch to disable http throttling on
our main app which will never be checked in, a patch for a major refactoring
of the data layer that might not fly, but the work is more significant than a
couple days work, an upgrade to a new version of the sdk in another patch, a
re-working of the docs patch etc.... I qpush whatever I want to work on
between bug fixes which go directly to the development branch.

so something like....

    
    
       hg qpush --move nothrottle.patch
       hg qrfresh # repeat etc...
       hg qpop  # unapply patch from working directory
       hg qpush --move membership_schema_refactor.patch
       hg qrefresh # repeat etc.... 
       hg qpop #unapply I haz bug to fix
       hg commit -m "fix this bug"
       hg push && hg pull && hg update development # do the sync dance
       hg qpush --move membership_schema_refactor.patch
       hg qfinish -a # change applied patches to changeset
    
    

Between the popping in pushing, I can switch to whichever branch revision I
want assuming whichever patch applies cleanly.

Not saying it's the same as the hypothetical workflow in git, but it is how I
handle multiple seemingly unrelated lines of development for better or worse.
Hell of a lot more flexible than what I would have to do in perforce before
they added shelving etc.... :)

~~~
regularfry
It does seem that mercurial is encouraging a workflow which is basically "get
everything into one patch before committing it" whereas git says "take as many
commits as you want to get it right, you can squash it later if you want."

~~~
tbatterii
based on my example, yeah I can see where you would think that.

But that example wasn't meant to be the definitive be all end all hg workflow.
just an example of how one person(me) keeps multiple lines of unrelated
development straight in their head.

Changesets can be converted to patches, patches can be folded into patches,
series of one or more patches can be converted to one or more changesets. IMO,
if there's any edge case that all that doesn't provide, I probably don't need
it.

------
tbatterii
I think this site goes a long way towards explaining things.

<http://gitvsmercurial.com/>

~~~
sausagefeet
I think for picking one that is fair, but I'd enjoy a good breakdown on how to
think about each on their own so I don't try to use git like hg or vice versa.

~~~
tbatterii
I use both, so obviously I enjoy a good breakdown as well(often switching
between the 2 several times a day).

And yeah, don't use hg like git and dont use git like hg unless you want pain.

But the author of this post comes off as an annoying zealot. So it is helpful
to "keep it real" by recognizing that they are both tools, so in the end as
the site says "who the fuck cares?", and master debators blog posts about the
supposed "better" or "worse" is just stupid.

The information is good, this authors choice of delivery is annoying. The "vc
tool war" if there ever was one was centralized vs distributed, and we the
developers won, now let's all go build something awesome.

------
k_bx
> When you are done with the ‘quick-fix’ branch, you can just remove it, and
> nobody has to know it existed

Well, I actually want to know about branches. If someone finishes work on some
branch, he'll just close it after merge. Also, "hg branch" command will sort
out non-merged branches from merged. This is so handy.

One thing that bugs me in git branches is that only gitk shows branches (in
git's strange way, when topmost commit has tons of branches assigned to it),
while in mercurial nearly all clients show branch info beside commit, since
it's a core feature and it's stored in commit.

I am now working with git for >6 month (after >1 year work with hg) and every
time I feel some mess with branches/merges it feels very uncomfortable.

So, for non-huge projects, hg branches are super-great, imo.

