4 ms·

>But for smaller projects, maintaining a truthful history is much more valuable. Elaborate. >Mercurial supports git's branching model and a lot of others. Ex

>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.

babyrainbow 10y ago
> Elaborate For example, to answer questions like "What feature was this commit part of, originally". "How and where did the merges happened?". To answer these questions months after the merges happened, even after you did't think that you would need to answer these questions, something like the workflows mercurial is essential. >Except, it doesn't completely. Elaborate? >Yes, because command line flags are ubiquitous in nearly every single tool Ok. But that does not mean that it is powerful enough and can be a replacement for or better than a proper query laguage.. > arbitrary DSL that has no convention behind it What convention? I am not getting you. >can be easily parsed by other tools in the same ecosystem. Parse what exactly? >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. Oh it does support it plenty. Take a look at the vocabulary supported by revsets in form of intuitive and easy to remember predicates. I don't think you are really impartial if you are not convinced by it.
- justinlaster 10y ago
  >to answer questions like "What feature was this commit part of, originally" Neither system will answer that. If you're relying on branches to tell you what feature sets changes belong to, you should be adding that to your commits. >"How and where did the merges happened?" Git will do this faster and in a more correct manner. In a complicated history graph, Mercurial will actually hide information from you if you try to query it and sometimes even mislead you. I'm starting to think you haven't used either system extensively. >Parse what exactly? Arguments and output. >Oh it does support it plenty. It does not. If you can't give an example, you can just admit that you don't know what you're talking about.
  - babyrainbow 10y ago
    >Neither system will answer that.... I am not sure what you are talking about. Every change set in Mercurial contain the branch in which it was made. Even after a merge, there is a clear distinction about the commits made in a certain branch. I think you might be thinking of rebased change sets. In that case, you would be right. >Git will do this faster and in a more correct manner.. Please show an example. I would also like to see an instance where Mercurial hiding information from you and giving misleading answers to your queries. >Arguments and output. But it is supposed to be used by people. So it should be first human friendly. And there is nothing stopping you from parsing output of mercurial commands. And what is the use case of parsing arguments? Why did you think so? Mercurial has even a template feature letting you format the output in any way you want. I am not sure, it seems to me that you are not making a whole lot of sense.. >If you can't give an example, you can just admit that you don't know what you're talking about. There are some examples at the bottom of the revset page I linked. Knock yourself out. And do share some examples of your claims, because your last commits contained enough stuff to doubt your experience..(stuff about conventions and DSLs, what was that again?)
    - justinlaster 10y ago
      > I would also like to see an instance where Mercurial hiding information from you and giving misleading answers to your queries. A branch with two heads. Two branches that have the same name. Which commit came from where? What happens if that branch was merged into the other? Or what happens if only one got merged into a "mainline" branch, while the other one was reverted else where. It's useless information at best, and misleading at worse. >But it is supposed to be used by people. So it should be first human friendly. You're going to claim a DSL that you have to research is somehow easier to use than simple command line arguments that have decades of convention behind them? Odd. Git allows you to format output as well. Not sure why you felt the need to bring that up. Again, unless you've extensively used both systems I'm not sure why you feel the need to argue because it's making you look foolish. >There are some examples at the bottom of the revset page I linked. And absolutely none of them help your argument.

babyrainbow 10y ago

> Elaborate For example, to answer questions like "What feature was this commit part of, originally". "How and where did the merges happened?". To answer these questions months after the merges happened, even after you did't think that you would need to answer these questions, something like the workflows mercurial is essential. >Except, it doesn't completely. Elaborate? >Yes, because command line flags are ubiquitous in nearly every single tool Ok. But that does not mean that it is powerful enough and can be a replacement for or better than a proper query laguage.. > arbitrary DSL that has no convention behind it What convention? I am not getting you. >can be easily parsed by other tools in the same ecosystem. Parse what exactly? >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. Oh it does support it plenty. Take a look at the vocabulary supported by revsets in form of intuitive and easy to remember predicates. I don't think you are really impartial if you are not convinced by it.

justinlaster 10y ago
>to answer questions like "What feature was this commit part of, originally" Neither system will answer that. If you're relying on branches to tell you what feature sets changes belong to, you should be adding that to your commits. >"How and where did the merges happened?" Git will do this faster and in a more correct manner. In a complicated history graph, Mercurial will actually hide information from you if you try to query it and sometimes even mislead you. I'm starting to think you haven't used either system extensively. >Parse what exactly? Arguments and output. >Oh it does support it plenty. It does not. If you can't give an example, you can just admit that you don't know what you're talking about.
- babyrainbow 10y ago
  >Neither system will answer that.... I am not sure what you are talking about. Every change set in Mercurial contain the branch in which it was made. Even after a merge, there is a clear distinction about the commits made in a certain branch. I think you might be thinking of rebased change sets. In that case, you would be right. >Git will do this faster and in a more correct manner.. Please show an example. I would also like to see an instance where Mercurial hiding information from you and giving misleading answers to your queries. >Arguments and output. But it is supposed to be used by people. So it should be first human friendly. And there is nothing stopping you from parsing output of mercurial commands. And what is the use case of parsing arguments? Why did you think so? Mercurial has even a template feature letting you format the output in any way you want. I am not sure, it seems to me that you are not making a whole lot of sense.. >If you can't give an example, you can just admit that you don't know what you're talking about. There are some examples at the bottom of the revset page I linked. Knock yourself out. And do share some examples of your claims, because your last commits contained enough stuff to doubt your experience..(stuff about conventions and DSLs, what was that again?)
  - justinlaster 10y ago
    > I would also like to see an instance where Mercurial hiding information from you and giving misleading answers to your queries. A branch with two heads. Two branches that have the same name. Which commit came from where? What happens if that branch was merged into the other? Or what happens if only one got merged into a "mainline" branch, while the other one was reverted else where. It's useless information at best, and misleading at worse. >But it is supposed to be used by people. So it should be first human friendly. You're going to claim a DSL that you have to research is somehow easier to use than simple command line arguments that have decades of convention behind them? Odd. Git allows you to format output as well. Not sure why you felt the need to bring that up. Again, unless you've extensively used both systems I'm not sure why you feel the need to argue because it's making you look foolish. >There are some examples at the bottom of the revset page I linked. And absolutely none of them help your argument.