[ezst]

I'd like to fill up some inaccuracies in your response:

- rebasing in Mercurial simply means chopping a subtree off of the history and re-attaching it to a different parent commit. In that sense, rebasing is a very useful and common history-rewriting operation. In fact, it's even simpler and more powerful/versatile than in git, because mercurial couldn't care less if the sub-tree you are rebasing belongs to a branch or not: it's just a DAG. It gets transplanted from A to B. A may or may not be your checked commit, or be the tip of a branch, doesn't matter.

- that mercurial requires a configuration toggle before rebasing can be used (i.e. that the user need to enable the extension explicitly) is a way to encourage interested users to learn their tool, and grow its capabilities together with their knowledge. It's opinionated, it may be too much hand-holding for some, but there is an elegant simplicity in keeping the help pages and autocomplete commands just as complex as the user can take it.

[qsera]

> rebasing in Mercurial simply means chopping...

Sure, but since commits have a branch attribute attached to them, "rebasing" does not appear to be "first class". It is something that has to be bolted on with an extension.

> because mercurial couldn't care less if the sub-tree you are rebasing belongs to a branch or not

IIUC Git also does not care much about the rebase target being a "branch".

I agree that Mercurial provides more value out of the box than git because it preserves branch info in commits.

I can live with Git because Git is "enough" if used carefully and after coming to terms with the non-intutive UI.

[ezst]

> Sure, but since commits have a branch attribute attached to them, "rebasing" does not appear to be "first class".

Again, that's orthogonal: you may or may not use "named branches" (the kind of which persists at commit level), rebasing works either way consistently and predictably.

> It is something that has to be bolted on with an extension.

The extension ships in core, UX is why it's not enabled by default.

> IIUC Git also does not care much about the rebase target being a "branch".

Indeed, it's just that things likely get weird (for no good reason) when you don't (detached head, "unreachable" commits)

> I can live with Git because Git is "enough" if used carefully and after coming to terms with the non-intutive UI.

That's our sad state of affairs. JJ helps a bit, though.