6 ms·

>branches give you a way to track the branches a commit is a part of which is good for long-running branches I think you have a slight misunderstanding on the

>branches give you a way to track the branches a commit is a part of which is good for long-running branches I think you have a slight misunderstanding on the differences between git and mercurial, as git absolutely allows you to do this. Mercurial tends to track this information in a way where it actually limits telling you what branches a commit is contained in. Git will tell you straight up which branches lead back to a commit (i.e., being contained in them). Mercurial tends to only give you immediate, direct ancestors, any kind of complicated history and Mercurial can't be bothered to actually to dive in and tell you what branches a commit is really apart of. That seems to be strangely counter-intuitive for "long running branches." Git doesn't need an equivalent of Mercurial branches and bookmarks, because git branches do everything both of those mercurial features do and more, in a far more lightweight and efficient manner contained in a clean, singular feature.

babyrainbow 10y ago
Mercurial records in every commit, that branch it was made. It is part of it's identity. That is what the parent is talking about. Git does not do this. Because git does not have this concept of named branches. In other words, Mercurial has feature branches, while git has developer branches. This gives much more possible workflows in case of Mercurial. >Mercurial tends to only give you immediate, direct ancestors, any kind of complicated history and Mercurial can't be bothered to actually to dive in and tell you what branches a commit is really apart of... http://stackoverflow.com/questions/7166011/mercurial-find-all-branches-where-commit-exists http://stackoverflow.com/questions/7166011/mercurial-find-al... Is that what you are talking about? Mercurial contains vastly more querying capabilities in the form of revsets. No such thing exists for Git. If you go head to head with git vs mercurial, git will loose pathetically.
- justinlaster 10y ago
  >Git does not do this. Because git does not have this concept of named branches. It doesn't pre-bake the information in the commit, because it's entirely useless information to bake into a commit; and even in the case of Mercurial can paint the wrong picture about the nature of a commit given branches that it's on. >This gives much more possible workflows in case of Mercurial. That is the exact opposite of what it gives you. I'm not even sure how you possibly arrived at that conclusion. >Mercurial contains vastly more querying capabilities in the form of revsets. Git doesn't need a query language, because you can literally do everything revsets will give you with git log and then maybe some very elementary bash script knowledge. You are literally arguing that Mercurial having its own arbitrary DSL is somehow better than git being able to seamlessly use popular tooling with conventional command line syntax; which seems to be at odds with the whole "mercurial is easier to use." I take extreme issue with your claim that Mercurial has "vastly" more querying capabilities and then you not even give one measly example.
  - babyrainbow 10y ago
    >because it's entirely useless information to bake into a commit; I have found it very useful in untangling a complex history. You might not see the value in it becuase git does not care to maintain a truthful history, but promotes building a "clean" history. It makes sense to do that if you are maintaing somethign like linux kernal. But for smaller projects, maintaining a truthful history is much more valuable. So I would say that it is extremely valuable information in the context of Mercurial. And there are other version control systems that follow similar model. Take a look at the '3.3 Branches' heading in another fantastic version control system called 'Fossil' here [1]. >That is the exact opposite of what it gives you. I'm not even sure how you possibly arrived at that conclusion. Well, Mercurial supports git's branching model and a lot of others. I am not sure how that is not clear. >Git doesn't need a query language... Of course. It is not meant to be used by mere mortals.. >because you can literally do everything revsets will give you with git log ... Are you seriously saying that using command line flags is more powerful and easier than using a query language that lets you use arbitrarily expressions to query a data set? > I take extreme issue with your claim that Mercurial has "vastly" more querying capabilities and then you not even give one measly example. Checkout the link I mentioned in my earlier comment. This is the manual page for revsets [2]. Please take a look. [1] http://www.fossil-scm.org/fossil/doc/trunk:2012-01-01/www/fossil-v-git.wiki http://www.fossil-scm.org/fossil/doc/trunk:2012-01-01/www/fo... [2] https://www.mercurial-scm.org/repo/hg/help/revsets https://www.mercurial-scm.org/repo/hg/help/revsets
    - justinlaster 10y ago
      >But for smaller projects, maintaining a truthful history is much more valuable. Elaborate. >Mercurial supports git's branching model and a lot of others. Except, it doesn't completely. >Are you seriously saying that using command line flags is more powerful and easier than using a query language that lets you use arbitrarily expressions to query a data set? Yes, because command line flags are ubiquitous in nearly every single tool, versus an arbitrary DSL that has no convention behind it, or can be easily parsed by other tools in the same ecosystem. > Please take a look. You seem to be under the impression that I have not or do not use Mercurial. You would be mistaken. Both of those pages do not lend support to your claim that the ability to "query" (with or without a DSL) the history graph is somehow superior in Mercurial. They merely document the feature, but do not draw any meaningful comparisons highlighting what it can do that git log or even git rev-list (which git log uses) can't.
AlexMax 10y ago
> Git doesn't need an equivalent of Mercurial branches and bookmarks, because git branches do everything both of those mercurial features do and more, in a far more lightweight and efficient manner contained in a clean, singular feature. Not quite everything. Since Mercurial branch names are baked into the commit, if you wanted to know which branch a commit was originally part of, you can find out. Git does not support this. If two branches have parent commits in common, it technically belongs to both branches. There is a valid conversation to be had on if this feature is actually necessary or makes sense in the context of a DVCS, but git branches are not a full substitute for Mercurial branches.
- justinlaster 10y ago
  > If two branches have parent commits in common, it technically belongs to both branches. It belongs to both branches as well in Mercurial, it just hides that information from you. An astoundingly bad idea, no? I'm not sure how mercurial hiding information from you is a "feature" in any sense of the word.
  - binarycrusader 10y ago
    Hiding or encapsulating information is arguably part of the very nature of an abstraction; the CLIs provided by git and Mercurial could be considered an abstraction of the implementation details of the respective technologies. As such, I fully expect each tool to hide some amount of information so that I don't have to think about the details.
    - justinlaster 10y ago
      There's no easy quick way to represent the actual state of the commit. It's far easier in git because it's the only way to do it. Furthermore, then information being "encapsulated" can actually become stale or misleading in Mercurial.

babyrainbow 10y ago

Mercurial records in every commit, that branch it was made. It is part of it's identity. That is what the parent is talking about. Git does not do this. Because git does not have this concept of named branches. In other words, Mercurial has feature branches, while git has developer branches. This gives much more possible workflows in case of Mercurial. >Mercurial tends to only give you immediate, direct ancestors, any kind of complicated history and Mercurial can't be bothered to actually to dive in and tell you what branches a commit is really apart of... http://stackoverflow.com/questions/7166011/mercurial-find-all-branches-where-commit-exists http://stackoverflow.com/questions/7166011/mercurial-find-al... Is that what you are talking about? Mercurial contains vastly more querying capabilities in the form of revsets. No such thing exists for Git. If you go head to head with git vs mercurial, git will loose pathetically.

justinlaster 10y ago
>Git does not do this. Because git does not have this concept of named branches. It doesn't pre-bake the information in the commit, because it's entirely useless information to bake into a commit; and even in the case of Mercurial can paint the wrong picture about the nature of a commit given branches that it's on. >This gives much more possible workflows in case of Mercurial. That is the exact opposite of what it gives you. I'm not even sure how you possibly arrived at that conclusion. >Mercurial contains vastly more querying capabilities in the form of revsets. Git doesn't need a query language, because you can literally do everything revsets will give you with git log and then maybe some very elementary bash script knowledge. You are literally arguing that Mercurial having its own arbitrary DSL is somehow better than git being able to seamlessly use popular tooling with conventional command line syntax; which seems to be at odds with the whole "mercurial is easier to use." I take extreme issue with your claim that Mercurial has "vastly" more querying capabilities and then you not even give one measly example.
- babyrainbow 10y ago
  >because it's entirely useless information to bake into a commit; I have found it very useful in untangling a complex history. You might not see the value in it becuase git does not care to maintain a truthful history, but promotes building a "clean" history. It makes sense to do that if you are maintaing somethign like linux kernal. But for smaller projects, maintaining a truthful history is much more valuable. So I would say that it is extremely valuable information in the context of Mercurial. And there are other version control systems that follow similar model. Take a look at the '3.3 Branches' heading in another fantastic version control system called 'Fossil' here [1]. >That is the exact opposite of what it gives you. I'm not even sure how you possibly arrived at that conclusion. Well, Mercurial supports git's branching model and a lot of others. I am not sure how that is not clear. >Git doesn't need a query language... Of course. It is not meant to be used by mere mortals.. >because you can literally do everything revsets will give you with git log ... Are you seriously saying that using command line flags is more powerful and easier than using a query language that lets you use arbitrarily expressions to query a data set? > I take extreme issue with your claim that Mercurial has "vastly" more querying capabilities and then you not even give one measly example. Checkout the link I mentioned in my earlier comment. This is the manual page for revsets [2]. Please take a look. [1] http://www.fossil-scm.org/fossil/doc/trunk:2012-01-01/www/fossil-v-git.wiki http://www.fossil-scm.org/fossil/doc/trunk:2012-01-01/www/fo... [2] https://www.mercurial-scm.org/repo/hg/help/revsets https://www.mercurial-scm.org/repo/hg/help/revsets
  - justinlaster 10y ago
    >But for smaller projects, maintaining a truthful history is much more valuable. Elaborate. >Mercurial supports git's branching model and a lot of others. Except, it doesn't completely. >Are you seriously saying that using command line flags is more powerful and easier than using a query language that lets you use arbitrarily expressions to query a data set? Yes, because command line flags are ubiquitous in nearly every single tool, versus an arbitrary DSL that has no convention behind it, or can be easily parsed by other tools in the same ecosystem. > Please take a look. You seem to be under the impression that I have not or do not use Mercurial. You would be mistaken. Both of those pages do not lend support to your claim that the ability to "query" (with or without a DSL) the history graph is somehow superior in Mercurial. They merely document the feature, but do not draw any meaningful comparisons highlighting what it can do that git log or even git rev-list (which git log uses) can't.

AlexMax 10y ago

> Git doesn't need an equivalent of Mercurial branches and bookmarks, because git branches do everything both of those mercurial features do and more, in a far more lightweight and efficient manner contained in a clean, singular feature. Not quite everything. Since Mercurial branch names are baked into the commit, if you wanted to know which branch a commit was originally part of, you can find out. Git does not support this. If two branches have parent commits in common, it technically belongs to both branches. There is a valid conversation to be had on if this feature is actually necessary or makes sense in the context of a DVCS, but git branches are not a full substitute for Mercurial branches.

justinlaster 10y ago
> If two branches have parent commits in common, it technically belongs to both branches. It belongs to both branches as well in Mercurial, it just hides that information from you. An astoundingly bad idea, no? I'm not sure how mercurial hiding information from you is a "feature" in any sense of the word.
- binarycrusader 10y ago
  Hiding or encapsulating information is arguably part of the very nature of an abstraction; the CLIs provided by git and Mercurial could be considered an abstraction of the implementation details of the respective technologies. As such, I fully expect each tool to hide some amount of information so that I don't have to think about the details.
  - justinlaster 10y ago
    There's no easy quick way to represent the actual state of the commit. It's far easier in git because it's the only way to do it. Furthermore, then information being "encapsulated" can actually become stale or misleading in Mercurial.