> It's useless information at best, and misleading at worse.
It seems useless to you because you see it from a git viewpoint. It is clear when you say that "Two branches that have the same name". It is not "two branches", but one branch with two heads. In Mercurial, a Branch is a set of commits. That view is incompatible with the thing that git call "branches".
If you think about it, Mercurial's implementation of a Branch is closer to the idea of a "Branch". As I told earlier, Mercurial branches are "Feature" branches". I am not sure if you have gone through the fossil doc page I linked earlier. When you see it like that, it makes complete sense that a Branch can have any number of heads. Say, the second head containing a different implementation of the same feature.
(God I miss Mercurial)
>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.
These questions are the result of trying to make sense of Mercurial branches in a GIt way..
>what happens if only one got merged into a "mainline" branch, while the other one was reverted else where.
Again, this question is a result of you seeing mercurial branches in a git way. Because git define a branch as the set of commits starting from a "head", the idea of merging only one of the heads does not make sense to you.
But you can do the same with git, right. You can move back couple of commits from a head and create a new head by starting committing from there. Only that in git, the previous head would be hidden. And you will have to go to the reflog to dig them up. But in Mercurial, things are much clearer and exposed (contrary to your accusation of it hiding and misleading).
So again, it feels misleading to you because it is different from git. It is very consistent in conforming to its on model.
>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.
I am not at all getting you here. "command line arguments that have decades of convention"? What exactly does that mean? And what is the thing about "a DSL that you have to research"?. You don't have to look up command line arguments of git? And you call git's command line arguments simple?
>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.
I didn't claim that git does not allow you to format the output, but just that Mercurial allows you to do that so that your argument about easily parseable output is moot.
It seems useless to you because you see it from a git viewpoint. It is clear when you say that "Two branches that have the same name". It is not "two branches", but one branch with two heads. In Mercurial, a Branch is a set of commits. That view is incompatible with the thing that git call "branches".
If you think about it, Mercurial's implementation of a Branch is closer to the idea of a "Branch". As I told earlier, Mercurial branches are "Feature" branches". I am not sure if you have gone through the fossil doc page I linked earlier. When you see it like that, it makes complete sense that a Branch can have any number of heads. Say, the second head containing a different implementation of the same feature.
(God I miss Mercurial)
>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.
These questions are the result of trying to make sense of Mercurial branches in a GIt way..
>what happens if only one got merged into a "mainline" branch, while the other one was reverted else where.
Again, this question is a result of you seeing mercurial branches in a git way. Because git define a branch as the set of commits starting from a "head", the idea of merging only one of the heads does not make sense to you.
But you can do the same with git, right. You can move back couple of commits from a head and create a new head by starting committing from there. Only that in git, the previous head would be hidden. And you will have to go to the reflog to dig them up. But in Mercurial, things are much clearer and exposed (contrary to your accusation of it hiding and misleading).
So again, it feels misleading to you because it is different from git. It is very consistent in conforming to its on model.
>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.
I am not at all getting you here. "command line arguments that have decades of convention"? What exactly does that mean? And what is the thing about "a DSL that you have to research"?. You don't have to look up command line arguments of git? And you call git's command line arguments simple?
>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.
I didn't claim that git does not allow you to format the output, but just that Mercurial allows you to do that so that your argument about easily parseable output is moot.