[qsera]

Mercurial's model is different from Git that these things you list does not make sense there.

Rebase does not make sense in Mercurial because it has the concept of fixed branches. A commit is permanently linked to the branch on which it was made. So you are supposed to use merges.

Same with force-pushing.

[windward]

I know. It's an opinion about how to develop that a lot of people hold - a declining proportion, mind you, like Mecurial's declining market share - and it's one that they're able to represent in Git's model, with Git's features. They're even able to do it without exposing me to it. But the same isn't true in reverse. Strictly superior?

Believe me, I tried to have an open mind about it. Then one day I was getting ready to go on a work trip with a half-finished feature on my work laptop, and realised there was simply no in-model way for backing that wip up to the repo. If I lost my laptop, I lost the progress. mercurial-scm fails at SCM.

[qsera]

>in-model way for backing that wip up to the repo.

That is because you have this notion of a "clean history", (which IIUC prevented you from making this permanent wip commit) which in reality does not have a lot of use. For most project, "useful history" or "real history" is better than a "clean" history.

That is what mercurial caters to.

[windward]

>For most project, "useful history" or "real history" is better than a "clean" history.

This is your opinion, so I'm compelled to point out it's not the consensus opinion.

[qsera]

Everything that I say is my opinion. I don't parrot consensus.

[ezst]

> one that they're able to represent in Git's model, with Git's features. They're even able to do it without exposing me to it. But the same isn't true in reverse. Strictly superior?

not sure what you mean to say, but for thoroughness' sake, no: git and mercurial concepts are not interchangeable, with git having mostly an inferior model.

To give examples: git has no concept of branching (in the way every VCS but Git uses the term). A branch in git is merely a tag on the tip of a series meant to signify that all ancestors belong to the same lineage. This comes with the implication that this lineage information is totally lost when two branches merge (you can't tell which side of the merge corresponded to which lineage). The ugly and generalised workaround is to abuse commit message (e.g. "merge feat-ABC into main") to store an essential piece of the repository history that the VCS cannot take.

Another example is phasing: mercurial records at commit level whether it was exchanged with others or not. That draws a clean line between the history that's always safe to rewrite, and which that is subject to conflicting merges if the person you shared those commits with also happened to rewrite them on their end.

> Then one day I was getting ready to go on a work trip with a half-finished feature on my work laptop, and realised there was simply no in-model way for backing that wip up to the repo. If I lost my laptop, I lost the progress. mercurial-scm fails at SCM.

Sorry to be blunt, but that's a skill issue: hg is no different than every other VCS in that regard. If you want your WIP changes to leave your laptop, you've got to push them somewhere, just like you would in git.

[windward]

>If you want your WIP changes to leave your laptop, you've got to push them somewhere, just like you would in git.

Permanently, to a single branch in un-buildable form. So useful.

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