3 ms·

> If using named branches is a problem just tell your devs to not use them and use bookmarks instead! but they do, because all the devs know git and are only

by zzzeek 13y ago

> If using named branches is a problem just tell your devs to not use them and use bookmarks instead! but they do, because all the devs know git and are only using mercurial because they want to send you a pull request, and now their feature branch is forever. Mecurial is unforgiving of mistakes - once in the repo, they are forever. As for MQ, I've really tried to understand it, but it's just profoundly awkward IMHO. Mercurial's main benefit is that it's much easier to use and understand than git, so if I'm going to need to fire up the extra brainpower, I might as well learn git where these advanced patterns are extremely commonplace, and are part of the core functionality, not as a series of optional extensions that have been bolted on over the years. I've almost never seen anyone using MQ or rebase with mercurial (or even bookmarks for that matter). I've tried carefully in my post to express that my points are all based on an overlap of social with technical issues. I am aware that technically, hg has answers for all these things. But these answers don't pan out in the real social world, for better or for worse. If git didn't exist, I'm sure there would be a much larger knowledge share for mercurial, and I was even betting on that in the beginning (certainly the "easier" tool will be more popular?) but it hasn't turned out that way.

rbehrends 13y ago
> As for MQ, I've really tried to understand it, but it's just profoundly awkward IMHO. Mercurial's main benefit is that it's much easier to use and understand than git, so if I'm going to need to fire up the extra brainpower, I might as well learn git where these advanced patterns are extremely commonplace. I've almost never seen anyone using MQ or rebase with mercurial. I believe the GP's reference to mq is for the strip command (to delete unwanted revisions), which for some odd reason that I've never understood is part of the mq extension.
ezquerra 13y ago
If I want to contribute to a project I don't expect them to accommodate my workflow. I expect to be asked to comply with their workflow. Let's say that I were the maintainer of a project in which we did not want to use named branches. If I got a pull request from someone that had created a named branch I would just kindly ask the contributor to remake his pull request, using bookmarks rather than a named branch. The fact that they made a mistake _on their repo_ does not mean that that same mistake must end up on _my_ repo.As I said this is just a social problem. You say that mercurial is unforgiving of mistakes. I say that mercurial makes sure that your _shared_ history is not lost. You can edit unshared history as much as you want. As for MQ... I would say that it is an acquired taste :-> If you don't like it there are some good alternatives, such as histedit (also a built-in extension) and the new evolve extension which is still a work in progress but which already lets you safely edit _shared_ history.
- deleted 13y ago
  [deleted]
dlitz 13y ago
> Mercurial's main benefit is that it's much easier to use and understand than git That's really only true if you're a beginner and you weren't properly taught how git actually works. Fundamentally, git's data model is really simple and transparent. The commands are somewhat arbitrary, but no moreso than Vim's or Emacs's. As with Vim and Emacs, you don't need to know most of the commands anyway, except for convenience.
- marssaxman 13y ago
  The simplicity of git's data model is the root of the problem; that is the reason it is hard to learn and hard to use. It operates at a lower level of abstraction than the level we are thinking at when we are actually developing code. Git is less of a version-control system and more of a library one could use to build one, but in absence of any canonical high-level git wrapper, we all end up implementing and running one in our heads. This is a waste of brain-power.
  - andrewflnr 13y ago
    Um, no. I think the git data model is perfectly good for real life version control. It turns out you don't need a higher level of abstraction. The problem IMO is that the UI doesn't map cleanly onto the natural operations on the data model. It might just be my ignorance, but the fact that I can have an operation in my head in terms of the git data model (which is fairly automatic) but not automatically know how to translate it into a git command is problematic.
  - lotyrin 13y ago
    To say I disagree is a massive understatement. I've seen teams try to use wrappers and just mess everything up because they don't understand what's actually going on in the underlying system. Git has the concepts it has because they're all important. It shows them all to unfiltered because to do so is vital.
    - marssaxman 13y ago
      HG seems to manage the same problem with less complexity.

by zzzeek 13y ago

rbehrends 13y ago

> As for MQ, I've really tried to understand it, but it's just profoundly awkward IMHO. Mercurial's main benefit is that it's much easier to use and understand than git, so if I'm going to need to fire up the extra brainpower, I might as well learn git where these advanced patterns are extremely commonplace. I've almost never seen anyone using MQ or rebase with mercurial. I believe the GP's reference to mq is for the strip command (to delete unwanted revisions), which for some odd reason that I've never understood is part of the mq extension.

ezquerra 13y ago

If I want to contribute to a project I don't expect them to accommodate my workflow. I expect to be asked to comply with their workflow. Let's say that I were the maintainer of a project in which we did not want to use named branches. If I got a pull request from someone that had created a named branch I would just kindly ask the contributor to remake his pull request, using bookmarks rather than a named branch. The fact that they made a mistake _on their repo_ does not mean that that same mistake must end up on _my_ repo.As I said this is just a social problem. You say that mercurial is unforgiving of mistakes. I say that mercurial makes sure that your _shared_ history is not lost. You can edit unshared history as much as you want. As for MQ... I would say that it is an acquired taste :-> If you don't like it there are some good alternatives, such as histedit (also a built-in extension) and the new evolve extension which is still a work in progress but which already lets you safely edit _shared_ history.

deleted 13y ago
[deleted]

dlitz 13y ago

> Mercurial's main benefit is that it's much easier to use and understand than git That's really only true if you're a beginner and you weren't properly taught how git actually works. Fundamentally, git's data model is really simple and transparent. The commands are somewhat arbitrary, but no moreso than Vim's or Emacs's. As with Vim and Emacs, you don't need to know most of the commands anyway, except for convenience.

marssaxman 13y ago
The simplicity of git's data model is the root of the problem; that is the reason it is hard to learn and hard to use. It operates at a lower level of abstraction than the level we are thinking at when we are actually developing code. Git is less of a version-control system and more of a library one could use to build one, but in absence of any canonical high-level git wrapper, we all end up implementing and running one in our heads. This is a waste of brain-power.
- andrewflnr 13y ago
  Um, no. I think the git data model is perfectly good for real life version control. It turns out you don't need a higher level of abstraction. The problem IMO is that the UI doesn't map cleanly onto the natural operations on the data model. It might just be my ignorance, but the fact that I can have an operation in my head in terms of the git data model (which is fairly automatic) but not automatically know how to translate it into a git command is problematic.
- lotyrin 13y ago
  To say I disagree is a massive understatement. I've seen teams try to use wrappers and just mess everything up because they don't understand what's actually going on in the underlying system. Git has the concepts it has because they're all important. It shows them all to unfiltered because to do so is vital.
  - marssaxman 13y ago
    HG seems to manage the same problem with less complexity.