4 ms·

It's not. hg users generally don't understand that git is doing something fundamentally different from hg. git adds a 3rd dimension to your file system. dimensi

It's not. hg users generally don't understand that git is doing something fundamentally different from hg. git adds a 3rd dimension to your file system. dimension 1 = files, dimension 2 = directories, dimension 3 = branch. That git adds this 3rd dimension makes it useful for version control but that's effectively a side effect. hg on the other hand is specifically about version control so it does not handle adding this 3rd dimension well. This is why for example things like gh-pages on github where there's a branch that has absolutely nothing to do with any other branch and no shared history is a normal thing to do in git (because a branch is another dimension to the file system, not a version control construct). That difference, adding branches as a 3rd dimension, is why git is more powerful. It's also a reason why a staging area is important to be able to precisely decide what goes in each branch since they may be unrelated. That is not to say that hg's ux isn't easier to understand than git's. It is easier. In part because it's trying to do something else. That is also not to excuse git's unintuitiveness.

yjftsjthsd-h 7y ago
> It's not. hg users generally don't understand that git is doing something fundamentally different from hg. > That is not to say that hg's ux isn't easier to understand than git's. It is easier. In part because it's trying to do something else. That is also not to excuse git's unintuitiveness. 1. So... it is, albeit perhaps by sacrificing certain features. 2. I'm not convinced that git's admissibly more powerful branching model justifies the claim that hg's UX is no nicer and people who prefer it just don't understand git. If nothing else, what practical difference is there between creating a branch with no history vs creating a branch with history and then clearing it out? (That is: `hg branch newbranch && rm -r * && hg commit . -m 'new start'`) Both hg and git boil down to DAGs and have generally similar tools available to manage the grand set of commits.
bogdanoff_2 7y ago
Just to clarify, in mercurial you can "branch off" and then merge back just like in git. The difference is that git has an explicit concept of "branch" and each commit must be part of a branch, whereas in hg each commit stands on its own and your history is just a graph of commits. Instead of using branches to indicate that you are working on different features, in hg you use bookmarks, which are just pointers to commits. In hg land, gh-pages would be a bookmark.
- gpderetta 7y ago
  I'm no expert, but isn't a branch in git just a label (i.e. a pointer) for a commit? In fact you can have orphaned commits in your reflog that are not pointed by any branch (and will be GC'd at some point). I guess you mean that hg commits do not have parent pointers and are thus not intrusively chained in trees, while an hg branch is a separate non-intrusive construct?
viraptor 7y ago
> hg on the other hand is specifically about version control so it does not handle adding this 3rd dimension well Bookmarks are in base distribution for many years now and work basically like git branches. They did work well.
alwillis 7y ago
That git adds this 3rd dimension makes it useful for version control but that's effectively a side effect. hg on the other hand is specifically about version control so it does not handle adding this 3rd dimension well. Not true in the least. hg has the same dimensions that git has, just implemented differently. hg’s branching model is actually a superset of what git does. A git branch is essentially the same as Mercurial's bookmarks. Mercurial also has named branches which are permanent and anonymous branching, which git doesn't have. You can read all about them at http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me....
alwillis 7y ago
I suppose Mercurial’s Phases [1] are another dimension—each commit can have the status of draft, public or secret. This is part of Mercurial’s Changeset evolution feature[2]. Your commits are in the Draft phase, which means they can be changed at any time. By default (this is configurable) when you push to your team’s repo, those changes become Public, which means they won't change and it’s safe to code or rebase on top of them. [1]: https://medium.com/@a_baez/mercurial-phases-introduction-4eecd838fed4 https://medium.com/@a_baez/mercurial-phases-introduction-4ee... [2]: https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/doc/evolution/

yjftsjthsd-h 7y ago

> It's not. hg users generally don't understand that git is doing something fundamentally different from hg. > That is not to say that hg's ux isn't easier to understand than git's. It is easier. In part because it's trying to do something else. That is also not to excuse git's unintuitiveness. 1. So... it is, albeit perhaps by sacrificing certain features. 2. I'm not convinced that git's admissibly more powerful branching model justifies the claim that hg's UX is no nicer and people who prefer it just don't understand git. If nothing else, what practical difference is there between creating a branch with no history vs creating a branch with history and then clearing it out? (That is: `hg branch newbranch && rm -r * && hg commit . -m 'new start'`) Both hg and git boil down to DAGs and have generally similar tools available to manage the grand set of commits.

bogdanoff_2 7y ago

Just to clarify, in mercurial you can "branch off" and then merge back just like in git. The difference is that git has an explicit concept of "branch" and each commit must be part of a branch, whereas in hg each commit stands on its own and your history is just a graph of commits. Instead of using branches to indicate that you are working on different features, in hg you use bookmarks, which are just pointers to commits. In hg land, gh-pages would be a bookmark.

gpderetta 7y ago
I'm no expert, but isn't a branch in git just a label (i.e. a pointer) for a commit? In fact you can have orphaned commits in your reflog that are not pointed by any branch (and will be GC'd at some point). I guess you mean that hg commits do not have parent pointers and are thus not intrusively chained in trees, while an hg branch is a separate non-intrusive construct?

viraptor 7y ago

> hg on the other hand is specifically about version control so it does not handle adding this 3rd dimension well Bookmarks are in base distribution for many years now and work basically like git branches. They did work well.

alwillis 7y ago

That git adds this 3rd dimension makes it useful for version control but that's effectively a side effect. hg on the other hand is specifically about version control so it does not handle adding this 3rd dimension well. Not true in the least. hg has the same dimensions that git has, just implemented differently. hg’s branching model is actually a superset of what git does. A git branch is essentially the same as Mercurial's bookmarks. Mercurial also has named branches which are permanent and anonymous branching, which git doesn't have. You can read all about them at http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me....

alwillis 7y ago

I suppose Mercurial’s Phases [1] are another dimension—each commit can have the status of draft, public or secret. This is part of Mercurial’s Changeset evolution feature[2]. Your commits are in the Draft phase, which means they can be changed at any time. By default (this is configurable) when you push to your team’s repo, those changes become Public, which means they won't change and it’s safe to code or rebase on top of them. [1]: https://medium.com/@a_baez/mercurial-phases-introduction-4eecd838fed4 https://medium.com/@a_baez/mercurial-phases-introduction-4ee... [2]: https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/doc/evolution/