3 ms·

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 dif

by ezst 6mo ago

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 6mo ago
> 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 6mo ago
  > 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.

by ezst 6mo ago

qsera 6mo ago

> 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 6mo ago
> 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.