5 ms·

Mercurial is not only simpler, but also has got really powerful features like revsets. http://www.selenic.com/hg/help/revsets http://www.selenic.com/hg/help/re

Mercurial is not only simpler, but also has got really powerful features like revsets. http://www.selenic.com/hg/help/revsets http://www.selenic.com/hg/help/revsets I have tried to switch to git multiple times. Every time, I keep coming back to Mercurial. The most difficulty I have with git is the non nonsensical naming of concepts. For eg, A branch is a pointer to a commit. Because of this, I experience a big mental block when I try to reason about something. With Mercurial this is very much easier. And if you are using a DVCS to any capacity you ll have to do this often. Another great thing about Mercurial is how easy to get help about stuff. You can head to the IRC chat room and can have a very good chance of catching one of the developers who, in my experience, were very helpful...

jordigh 12y ago
> Mercurial is not only simpler, but also has got really powerful features like revsets. Revsets together with templates can be used to build custom commands: http://jordi.inversethought.com/blog/customising-mercurial-like-a-pro/ http://jordi.inversethought.com/blog/customising-mercurial-l... There are also filesets that work similarly for doing queries on files (hg help filesets).
stormbrew 12y ago
> The most difficulty I have with git is the non nonsensical naming of concepts. For eg, A branch is a pointer to a commit. This is a frustrating thing about how people tend to talk negatively about git. I think what you mean is "not named in a way I'm used to," because there's nothing nonsensical about this naming at all, and it's actually an incredibly simple and lightweight way to reason about naming things in version control (imo, I suppose). And it permeates basically every level of how git organizes information in a pretty darn uniform way. To me mercurial's two kinds of built-in branches and several plugins to do branch-like things is much more complex, but I still wouldn't call it nonsensical. That'd just be admitting that I stopped thinking about it when it was strange and unfamiliar to me.
- imakesnowflakes 12y ago
  >I think what you mean is "not named in a way I'm used to,".. Of course, that is the whole point of naming something sensibility..Just, for example, imagine how hard it would be if you have to learn/work in a version of C that calls pointers as 'branches'. >To me Mercurial's two kinds of built-in branches and several plugins to do branch-like things is much more complex, but I still wouldn't call it nonsensical. I don't know what you mean by 'several plugins to do branch like things'. Isn't it more frustrating that people complain about a tool because they have to enable some advanced stuff by configuration. But I agree that Mercurial is actually complex than Git, because it provides more options to the user. So the complexity of Mercurial is a side effect of it being more powerful IMHO. So the point is I say, naming a 'pointer to a commit' as branch, is nonsensical because it goes against our notion of the word 'Branch' from real life. It adds unnecessary burden for a human being trying to think in the language of the tool, without actually making the tool more powerful. Git could have been as powerful as it is now even if it had named things better, Right?
  - stormbrew 12y ago
    > Of course, that is the whole point of naming something sensibility..Just, for example, imagine how hard it would be if you have to learn/work in a version of C that calls pointers as 'branches'. Yes, if you rename <arbitrary thing> to <other arbitrary thing>, it is very likely to result in nonsense. This is not such a case. A branch in git is literally a name for a branch of the DAG that is the commit tree. It's possibly the least abstract interpretation of the concept as possible. There is nothing nonsensical about it. But the objection seems to be that you don't work with it like in svn or hg or p4 or cvs (which are also all different from each other), which does not make it nonsensical, merely unfamiliar. This is the distinction I'm driving at.
    - imakesnowflakes 12y ago
      >But the objection seems to be that you don't work with it.. The objection is that, when naming is skewed in lower levels it makes it harder to reason about higher level concepts and creates ambiguity.. For example, let us continue with the idea of a 'branch'... Suppose you define a branch as 'a set of commits'. Then it is easy to imagine a 'remove' operation on a 'branch' will remove all the commits in that 'branch'. There is no ambiguity. But when you define a branch as 'a pointer to the last commit in a consecutive set of commits', a 'remove' operation on a branch is no longer clear what it is supposed to do. Does it simply deletes the pointer, in which case the commits will remain untouched? But it would not be consistent with the abstraction of the 'branch'. Does it remove all the child commits from the history? by which the operation would be consistent with the abstraction of a 'branch'. Now the remove operation is ambiguous as to what it actually does. Note that there would be no ambiguity if the user does not know that a branch is actually a pointer to a commit. Because git hides all the change-sets that are not the decedents of a branch. So a users concept of a 'branch removal' is maintained. But I think it is pretty accepted that using git requires that you know stuff like these... So another way of looking at the problem is that, Git forces the user to work at multiple levels of abstraction simultaneously. And this creates ambiguity because the user wouldn't know which level of abstraction to use when reasoning about something, and defeats the whole point of having abstractions in the first place IMHO.
LocalPCGuy 12y ago
Like stormbrew said, it's all in what you are used to. We currently have both a mercurial and a number of git repos for various projects, and we are seriously considering spending the time to migrate the mercurial repo to git. The context switching from one to the other is really hard, commands don't work the way you expect and things just feel wrong. Personally, I much prefer git, and I researched both before I used either. But I wouldn't fault someone for preferring mercurial, particularly if part of the reason was that they were very comfortable using it.
saraid216 12y ago
> For eg FYI, "e.g." stands for "exempli gratia" which is Latin for "For the sake of example". So "for eg" is actually "for for the sake of example". [1] http://en.wiktionary.org/wiki/e.g http://en.wiktionary.org/wiki/e.g.
- imakesnowflakes 12y ago
  Oh, I see. Thank you! :)

jordigh 12y ago

> Mercurial is not only simpler, but also has got really powerful features like revsets. Revsets together with templates can be used to build custom commands: http://jordi.inversethought.com/blog/customising-mercurial-like-a-pro/ http://jordi.inversethought.com/blog/customising-mercurial-l... There are also filesets that work similarly for doing queries on files (hg help filesets).

stormbrew 12y ago

> The most difficulty I have with git is the non nonsensical naming of concepts. For eg, A branch is a pointer to a commit. This is a frustrating thing about how people tend to talk negatively about git. I think what you mean is "not named in a way I'm used to," because there's nothing nonsensical about this naming at all, and it's actually an incredibly simple and lightweight way to reason about naming things in version control (imo, I suppose). And it permeates basically every level of how git organizes information in a pretty darn uniform way. To me mercurial's two kinds of built-in branches and several plugins to do branch-like things is much more complex, but I still wouldn't call it nonsensical. That'd just be admitting that I stopped thinking about it when it was strange and unfamiliar to me.

imakesnowflakes 12y ago
>I think what you mean is "not named in a way I'm used to,".. Of course, that is the whole point of naming something sensibility..Just, for example, imagine how hard it would be if you have to learn/work in a version of C that calls pointers as 'branches'. >To me Mercurial's two kinds of built-in branches and several plugins to do branch-like things is much more complex, but I still wouldn't call it nonsensical. I don't know what you mean by 'several plugins to do branch like things'. Isn't it more frustrating that people complain about a tool because they have to enable some advanced stuff by configuration. But I agree that Mercurial is actually complex than Git, because it provides more options to the user. So the complexity of Mercurial is a side effect of it being more powerful IMHO. So the point is I say, naming a 'pointer to a commit' as branch, is nonsensical because it goes against our notion of the word 'Branch' from real life. It adds unnecessary burden for a human being trying to think in the language of the tool, without actually making the tool more powerful. Git could have been as powerful as it is now even if it had named things better, Right?
- stormbrew 12y ago
  > Of course, that is the whole point of naming something sensibility..Just, for example, imagine how hard it would be if you have to learn/work in a version of C that calls pointers as 'branches'. Yes, if you rename <arbitrary thing> to <other arbitrary thing>, it is very likely to result in nonsense. This is not such a case. A branch in git is literally a name for a branch of the DAG that is the commit tree. It's possibly the least abstract interpretation of the concept as possible. There is nothing nonsensical about it. But the objection seems to be that you don't work with it like in svn or hg or p4 or cvs (which are also all different from each other), which does not make it nonsensical, merely unfamiliar. This is the distinction I'm driving at.
  - imakesnowflakes 12y ago
    >But the objection seems to be that you don't work with it.. The objection is that, when naming is skewed in lower levels it makes it harder to reason about higher level concepts and creates ambiguity.. For example, let us continue with the idea of a 'branch'... Suppose you define a branch as 'a set of commits'. Then it is easy to imagine a 'remove' operation on a 'branch' will remove all the commits in that 'branch'. There is no ambiguity. But when you define a branch as 'a pointer to the last commit in a consecutive set of commits', a 'remove' operation on a branch is no longer clear what it is supposed to do. Does it simply deletes the pointer, in which case the commits will remain untouched? But it would not be consistent with the abstraction of the 'branch'. Does it remove all the child commits from the history? by which the operation would be consistent with the abstraction of a 'branch'. Now the remove operation is ambiguous as to what it actually does. Note that there would be no ambiguity if the user does not know that a branch is actually a pointer to a commit. Because git hides all the change-sets that are not the decedents of a branch. So a users concept of a 'branch removal' is maintained. But I think it is pretty accepted that using git requires that you know stuff like these... So another way of looking at the problem is that, Git forces the user to work at multiple levels of abstraction simultaneously. And this creates ambiguity because the user wouldn't know which level of abstraction to use when reasoning about something, and defeats the whole point of having abstractions in the first place IMHO.

LocalPCGuy 12y ago

Like stormbrew said, it's all in what you are used to. We currently have both a mercurial and a number of git repos for various projects, and we are seriously considering spending the time to migrate the mercurial repo to git. The context switching from one to the other is really hard, commands don't work the way you expect and things just feel wrong. Personally, I much prefer git, and I researched both before I used either. But I wouldn't fault someone for preferring mercurial, particularly if part of the reason was that they were very comfortable using it.

saraid216 12y ago

> For eg FYI, "e.g." stands for "exempli gratia" which is Latin for "For the sake of example". So "for eg" is actually "for for the sake of example". [1] http://en.wiktionary.org/wiki/e.g http://en.wiktionary.org/wiki/e.g.

imakesnowflakes 12y ago
Oh, I see. Thank you! :)