3 ms·

> rebasing in Mercurial simply means chopping... Sure, but since commits have a branch attribute attached to them, "rebasing" does not appear to be "first clas

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