3 ms·

> There are benefits to having branches be an inherent property of a commit And drawbacks, naturally. Advanced branching/merging workflows become extremely pa

> There are benefits to having branches be an inherent property of a commit And drawbacks, naturally. Advanced branching/merging workflows become extremely painful if not impossible, which makes mercurial unusable as a "true" DVCS (where everyone maintains a fork of the code and people trade PRs/merges).

Dylan16807 3y ago
Like what? How does it differ from an extra line on each commit message saying the branch name, and some options to parse it if desired? I definitely get annoyed sometimes when I have to put in extra effort to figure out which side of the tree is which.
jcranmer 3y ago
> Advanced branching/merging workflows become extremely painful if not impossible That's really, really not true. First off, I used the word "inherent", which doesn't mean "immutable"; you can retain all the benefits of mutability if you so desire. Of course, Mercurial historically focused a lot heavier on immutable commits than Git did, but hg eventually found a different path that really makes using git feel antediluvian in comparison. The second thing to note is that there's no requirement that the 'branch' property of a commit correspond to only one head. Actually, I don't think any of the mercurial repositories I've contributed to ever bothered with branches; there's just simply no need in mercurial to create multiple named branches, the way there is in git. Finally, mercurial solves the workflow problem in another way, by essentially realizing that there is a dichotomy between public, immutable commits and work-in-progress draft commits. The problem with PRs is that you end up in a situation where you have the unenviable choice between making updates with 'address fixes' commits that pollute history or rebases that risk making comments go into the ether (especially on GitHub). You might have extra squashes or rebases that make PRs that depend on other PRs painful. Mercurial instead makes a rebase or other history edit simply mark the old commit as dead and link to the new version, so that any other commits that depend on it can know how to be updated to the new version. And this information is spread to anyone who pulls from your repo, but need not be retained when pushed to anyone who didn't know about the old dead versions!

Dylan16807 3y ago

Like what? How does it differ from an extra line on each commit message saying the branch name, and some options to parse it if desired? I definitely get annoyed sometimes when I have to put in extra effort to figure out which side of the tree is which.

jcranmer 3y ago

> Advanced branching/merging workflows become extremely painful if not impossible That's really, really not true. First off, I used the word "inherent", which doesn't mean "immutable"; you can retain all the benefits of mutability if you so desire. Of course, Mercurial historically focused a lot heavier on immutable commits than Git did, but hg eventually found a different path that really makes using git feel antediluvian in comparison. The second thing to note is that there's no requirement that the 'branch' property of a commit correspond to only one head. Actually, I don't think any of the mercurial repositories I've contributed to ever bothered with branches; there's just simply no need in mercurial to create multiple named branches, the way there is in git. Finally, mercurial solves the workflow problem in another way, by essentially realizing that there is a dichotomy between public, immutable commits and work-in-progress draft commits. The problem with PRs is that you end up in a situation where you have the unenviable choice between making updates with 'address fixes' commits that pollute history or rebases that risk making comments go into the ether (especially on GitHub). You might have extra squashes or rebases that make PRs that depend on other PRs painful. Mercurial instead makes a rebase or other history edit simply mark the old commit as dead and link to the new version, so that any other commits that depend on it can know how to be updated to the new version. And this information is spread to anyone who pulls from your repo, but need not be retained when pushed to anyone who didn't know about the old dead versions!