5 ms·

This is especially funny considering the huge discussion recently about rewriting curl and then the entire world in Rust, but imagine you lived in a world where

This is especially funny considering the huge discussion recently about rewriting curl and then the entire world in Rust, but imagine you lived in a world where the magical "better tool" already existed and all you had to do was discover it. Leaving fantasy-land aside for a moment, this morning you woke up in the real world. In the real world, that tool does already exist, and it's called Mercurial. If you try command-line Mercurial for long enough to get past the initial "oh no Windows/macOS/Linux got updates and moved all my icons" muscle-memory-refresh phase (and especially if you last long enough to get into revsets and templates), you'll find it extraordinarily difficult to go back to using command-line git. Your power grows with Mercurial as you learn more about it because you aren't constantly fighting the complete absence of idioms and opaque "man-page" style of documentation that puts a slab of inscrutable text front and centre and neglects to provide simple examples for common problems (apparently we have a perfectly good Stack Overflow for that). The git boosters will respond to this by saying, as they always do, "yes, but the real power of git is in the model of the information under the hood. The CLI is just an interface, if you don't like it you should spend months studying the internals and build your own workflow on top of git". Again, back in the real world, who has time for that? Or the interest? Especially when, as I already mentioned, that tool does already exist and it's called Mercurial and you can get started with it right now. Both tools can do close to exactly the same things under the hood with differences that won't make a lick of difference to the vast majority of users. The user-facing differences are where it really matters: one tool has an excellent CLI which is clear, concise and discoverable; the other has github. Damn. Lousy network effects.

paulddraper 10y ago
Mercurial is nowhere near the idilic interface you imply. E.g. I challenge you to figure out how to use its interface to delete a branch. http://stackoverflow.com/questions/41968796/how-to-delete-a-remote-branch-in-mercurial http://stackoverflow.com/questions/41968796/how-to-delete-a-...
- ngoldbaum 10y ago
  You can close a branch, which makes it stop appearing in the UI unless you explicitly ask for closed branches. You can never fully delete a branch since the branch is part of the commit metadata (as it should be, IMO).
  - rw_grim 10y ago
    not to mention that a git branch is NOT your typical VCS branch. It's an ephemeral named head, nothing more than a tag (that lives outside of the normal tag interface).
- rbehrends 10y ago
  This has nothing to do with the interface and everything with the policy choice of not having mutable history on the server. If you do enable mutable history (with evolve), then you do it with: hg prune <revisions you want to remove> hg push
curun1r 10y ago
FWIW, the re-written in Rust option is Pijul (https://pijul.org/ https://pijul.org/), not Mercurial. It's still very nascent, but has a lot of promise.
theamk 10y ago
The team I am on uses git because we want clean and linear commit history. This means "master" and private branches are very different: - private branches have lots of random commits which no one will care about once feature is done: "start on feature", "fix typo", "add test", "fix feature", "add interface to foobar", "fix a bug", "fix it for real", "add another function to foobar interface".. and so on - "master" has a nice, clean history. The corresponding commits would be : "add interfaces to foobar", "add feature" This means the developers are actually expected to squash/merge/reword their commits before submitting to master. The submit scripts also enforce ff-only merges, so the master is fully linear. We like this workflow because it has advantages of both SVN -- linear, easy-to-read history, and of git -- you can commit as often as you want and you can share your work easily. Now, we have users struggle with git periodically, but it looks that trying to use Mercurial in our workflow will be even worse -- most of the Mercurial references seem to disapprove of rebasing in general. Example: http://stackoverflow.com/questions/2672351/hg-how-to-do-a-rebase-like-gits-rebase http://stackoverflow.com/questions/2672351/hg-how-to-do-a-re... I understand that this is somewhat unusual workflow; but it illustrates the power of git. You can have a huge variety of the workflows, while Mercurial (and many others) push people towards a single preferred one. And sure, modern hg has "rebase" and "histedit", but they just seem like second-class citizens, and they are much less polished than git's (for example, histedit's man page says " If you drop a change, it's gone forever". Scary! I think I will just use git instead)
- sampo 10y ago
  Actually, Mercurial keeps all the deleted changesets in .hg/strip-backup. They will stay there forever, unless you delete them by hand.
- marcinkuzminski 10y ago
  Our team uses Mercurial for exactly the same thing, a clean linear history, with features like phases, and histedit it's very easy to achieve and works great. We use RhodeCode to manage pull requests for Mercurial. This has also a feature to rebase commits on merge.

paulddraper 10y ago

Mercurial is nowhere near the idilic interface you imply. E.g. I challenge you to figure out how to use its interface to delete a branch. http://stackoverflow.com/questions/41968796/how-to-delete-a-remote-branch-in-mercurial http://stackoverflow.com/questions/41968796/how-to-delete-a-...

ngoldbaum 10y ago
You can close a branch, which makes it stop appearing in the UI unless you explicitly ask for closed branches. You can never fully delete a branch since the branch is part of the commit metadata (as it should be, IMO).
- rw_grim 10y ago
  not to mention that a git branch is NOT your typical VCS branch. It's an ephemeral named head, nothing more than a tag (that lives outside of the normal tag interface).
rbehrends 10y ago
This has nothing to do with the interface and everything with the policy choice of not having mutable history on the server. If you do enable mutable history (with evolve), then you do it with: hg prune <revisions you want to remove> hg push

curun1r 10y ago

FWIW, the re-written in Rust option is Pijul (https://pijul.org/ https://pijul.org/), not Mercurial. It's still very nascent, but has a lot of promise.

theamk 10y ago

The team I am on uses git because we want clean and linear commit history. This means "master" and private branches are very different: - private branches have lots of random commits which no one will care about once feature is done: "start on feature", "fix typo", "add test", "fix feature", "add interface to foobar", "fix a bug", "fix it for real", "add another function to foobar interface".. and so on - "master" has a nice, clean history. The corresponding commits would be : "add interfaces to foobar", "add feature" This means the developers are actually expected to squash/merge/reword their commits before submitting to master. The submit scripts also enforce ff-only merges, so the master is fully linear. We like this workflow because it has advantages of both SVN -- linear, easy-to-read history, and of git -- you can commit as often as you want and you can share your work easily. Now, we have users struggle with git periodically, but it looks that trying to use Mercurial in our workflow will be even worse -- most of the Mercurial references seem to disapprove of rebasing in general. Example: http://stackoverflow.com/questions/2672351/hg-how-to-do-a-rebase-like-gits-rebase http://stackoverflow.com/questions/2672351/hg-how-to-do-a-re... I understand that this is somewhat unusual workflow; but it illustrates the power of git. You can have a huge variety of the workflows, while Mercurial (and many others) push people towards a single preferred one. And sure, modern hg has "rebase" and "histedit", but they just seem like second-class citizens, and they are much less polished than git's (for example, histedit's man page says " If you drop a change, it's gone forever". Scary! I think I will just use git instead)

sampo 10y ago
Actually, Mercurial keeps all the deleted changesets in .hg/strip-backup. They will stay there forever, unless you delete them by hand.
marcinkuzminski 10y ago
Our team uses Mercurial for exactly the same thing, a clean linear history, with features like phases, and histedit it's very easy to achieve and works great. We use RhodeCode to manage pull requests for Mercurial. This has also a feature to rebase commits on merge.