[t43562]

Mercurial was safer and better. I still use it and it's still safer.

The bookmarks feature which is supposed to be the solution for short-lived branches is hard to understand though. I'm probably dumb but I can't work it out and hence the overall tool is that much less useful.

It needs a github-like website and Heptapod would be great if I could use it - I've set up a project, been unable to do anything and then had it all closed down. OTOH self-hosting is a lot more feasible nowadays with today's fibre connections.

[ciupicri]

I hated so much how Mercurial dealt with short-lived branches, that after seeing how Git did it, I've never looked back. I also remember how some people told me to use the quilt or something extension to manage patches, but it was too complicated for me.

[seany]

It make a lot of sense if you think of repo history as properly immutable, and dispose of the notion that brach is a first class object in the git sense. Bookmakers just pin a checkin hash to a name, and you can have many heads in an hg branch.

[irishcoffee]

What does short lives branches even mean? Make a branch, close it, or merge it.

[interroboink]

Short-lived branches are likely referring to "bookmarks" in Mercurial. Or they could also just be un-named anonymous heads. These are different from what is exposed by the "hg branch" command.

Mercurial's "branch" was generally intended for long-lived things. Think the "stable branch" or a "version X" support branch for a project.

The branch name is baked into the commits that use it. You can hide them from the UI with "--close-branch", but they will still exist forever in the commit history. This is both a good thing and a bad thing, depending on your desires.

This is different from Git's "branch" which is basically just a pointer to a commit. It is not part of commit history, it is just a convenience for the developer. Later, Mercurial added "bookmarks" which are similar.

[ezst]

> The bookmarks feature which is supposed to be the solution for short-lived branches is hard to understand though.

yup, it came up as a response to git and people getting more and more re-wired into thinking of "branches as pointers", with its own bag of implicit state and behaviour. No wonder it felt clunky and unpolished used in this context. That said, it was a pretty effective way to globally distribute a namespace of string→commitID pairs, i.e. a list of commit bookmarks, and at least in that sense the feature wasn't a total misnomer/let-down :-)