5 ms·

God, it's probably billions. I love git but its user interface is borderline criminal. The sad thing is mercurial has like 95% of git's power and is waaay easie

God, it's probably billions. I love git but its user interface is borderline criminal. The sad thing is mercurial has like 95% of git's power and is waaay easier to understand, but it never took off in a big way.

exDM69 10y ago
> The sad thing is mercurial has like 95% of git's power and is waaay easier to understand Mercurial has a clean and simple UI, especially if you come from a SVN background. But Git's internals are simpler and the concept is much easier to understand, especially if you start looking at a handful of the most popular Mercurial extensions, some of which will be "must have" sooner or later. This is no excuse for an inconsistent UI in Git, but the damage is already done. There's no point in making major changes now (some renaming for consistency might be alright, though), it would be breaking existing workflows and scripts. I find the best explanation of how Git works is... the first commit of Git[0] itself. [0] https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290#diff-c47c7c7383225ab55ff591cb59c41e6bR1 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...
- marcinkuzminski 10y ago
  I think Mercurial is also great, and we also can provide some feedback as the platform that supports Mercurial as Source Code Management (RhodeCode). There are A LOT of mercurial users which are big companies, they just aren't so vocal on the internal like people using GIT. Mercurial has an established community, great plugability system, an awesome feature like phases. We see more and more people adopting Mercurial together with our product. I wish to see more advocates of Mercurial, it's a shame it doesn't get more public attention nowadays.
- BeetleB 10y ago
  >But Git's internals are simpler and the concept is much easier to understand, I'm only an occasional Git user, but am a heavy Mercurial user. I have never needed to understand Mercurial's internals. Are you suggesting a Git user will eventually need to understand it? That's a strike against Git already. From my observation over the years, people who use Git get "stuck" more often, because they are trying to leverage the extra power Git seems to provide. With Mercurial, you often can do similar powerful stuff, but they make sure you have to go through hoops to do it. As such, unsuspecting non-power users do not shoot themselves in the foot.
  - ubernostrum 10y ago
    Are you suggesting a Git user will eventually need to understand it? That's a strike against Git already. The typical advice -- which you'll see in this thread and elsewhere -- is that anyone who uses git should learn git's internals, and preferably up-front, since apparently that will magically cause git to make sense. I'm a bit put off by the idea, myself.
    - exDM69 10y ago
      Exactly. It's also worth looking at git internals because it's very elegant, clean and simple. In my opinion, one of the best designed software systems I've come across. I encourage you to look at the README in the first git commit, it's very enlightening.
  - jogjayr 10y ago
    > Are you suggesting a Git user will eventually need to understand it? That's a strike against Git already. I try to learn about git internals just for the pleasure of it.
  - whataretensors 10y ago
    >Are you suggesting a Git user will eventually need to understand it? That's a strike against Git already. I think as engineers we should understand how our tools work.
jlebar 10y ago
$ hg clone https://bitbucket.org/eigen/eigen/ $ cd eigen $ time hg grep CUDA > /dev/null real 0m16.661s user 0m16.097s sys 0m0.531s $ git clone https://github.com/RLovelett/eigen.git $ cd eigen $ time git grep CUDA > /dev/null real 0m0.019s user 0m0.035s sys 0m0.057s Never looked back.
- BeetleB 10y ago
  This is also why I prefer using C over Python. (End Sarcasm). Seriously? You're so productive that the cost of cloning a repository is a major impediment? The benefits of a cleaner interface mostly trump the benefits of speed.
  - jlebar 10y ago
    > Seriously? You're so productive that the cost of cloning a repository is a major impediment? Read the commands more carefully. It is not the cost of cloning the repository, but rather the cost of searching it.
    - BeetleB 10y ago
      Ah. My mistake. 16s is not a big deal, but I'm assuming it would get much worse for larger repositories. Personally, my searches are either: 1. Restricted to all files that end in cpp, h, py, pl, etc. 2. Explicitly exclude .hg directories. I'll confess: I use a nice tool to do my searches than typing it out in grep. Much handier. And it remembers previously used filters (.cpp,.h) and is usually the first item in the drop down box. Much quicker than typing out a grep command. Still, I feel if our team used git instead of hg, we'd lose a lot more time due to people not grokking git and making mistakes than the time lost in longer searches. My point still stands: Things like search time are not a productivity bottleneck. If all our searches were 100x faster, there would be no difference in our output.
      - Jtsummers 10y ago
        16 seconds versus a fraction of a second. There's a big difference, somewhere, in what these two systems are doing to accomplish (ostensibly) the same task. And if it's not accomplishing the same task, they shouldn't be using the same verb (grep) for it. And I disagree with this point: Things like search time are *not* a productivity bottleneck. I maintain old codebases. I don't know them by heart, I didn't write them and the documentation is often poor (for the codebase, the specs are usually decent, but that's the system spec, not the code spec). Search is critical for me to get around these things. A 16s search would be incredibly annoying and bottlenecking compared to one that's nearly instant. Not having looked at the internals of either, I wonder if this is related to other performance differences in grep implementations across *nix systems. EDIT: Exploring this, it seems they don't do the same thing? `git grep` searches, by default, only the most recent working tree or revision. It doesn't search every revision unless you tell it to. `hg grep` (don't have it installed) seems to search every revision by default, so restricting it to the current revision requires an explicit command line option specifying the revision range to search.
marcosdumay 10y ago
Yes, it does 95% of what git does, and very well. The problem, that I don't think anybody even expected, is that there are strong network effects on the selection of your CVS. That gives the tool that can handle more use cases a big advantage, and bigger still if those features are needed on the projects with more developers.
hobarrera 10y ago
Mercurial was a lot harder to understand for me, and had no staging index -- stuff is committed directly. I found that this made it incredibly hard to use, especially coming from git.

exDM69 10y ago

> The sad thing is mercurial has like 95% of git's power and is waaay easier to understand Mercurial has a clean and simple UI, especially if you come from a SVN background. But Git's internals are simpler and the concept is much easier to understand, especially if you start looking at a handful of the most popular Mercurial extensions, some of which will be "must have" sooner or later. This is no excuse for an inconsistent UI in Git, but the damage is already done. There's no point in making major changes now (some renaming for consistency might be alright, though), it would be breaking existing workflows and scripts. I find the best explanation of how Git works is... the first commit of Git[0] itself. [0] https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290#diff-c47c7c7383225ab55ff591cb59c41e6bR1 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...

marcinkuzminski 10y ago
I think Mercurial is also great, and we also can provide some feedback as the platform that supports Mercurial as Source Code Management (RhodeCode). There are A LOT of mercurial users which are big companies, they just aren't so vocal on the internal like people using GIT. Mercurial has an established community, great plugability system, an awesome feature like phases. We see more and more people adopting Mercurial together with our product. I wish to see more advocates of Mercurial, it's a shame it doesn't get more public attention nowadays.
BeetleB 10y ago
>But Git's internals are simpler and the concept is much easier to understand, I'm only an occasional Git user, but am a heavy Mercurial user. I have never needed to understand Mercurial's internals. Are you suggesting a Git user will eventually need to understand it? That's a strike against Git already. From my observation over the years, people who use Git get "stuck" more often, because they are trying to leverage the extra power Git seems to provide. With Mercurial, you often can do similar powerful stuff, but they make sure you have to go through hoops to do it. As such, unsuspecting non-power users do not shoot themselves in the foot.
- ubernostrum 10y ago
  Are you suggesting a Git user will eventually need to understand it? That's a strike against Git already. The typical advice -- which you'll see in this thread and elsewhere -- is that anyone who uses git should learn git's internals, and preferably up-front, since apparently that will magically cause git to make sense. I'm a bit put off by the idea, myself.
  - exDM69 10y ago
    Exactly. It's also worth looking at git internals because it's very elegant, clean and simple. In my opinion, one of the best designed software systems I've come across. I encourage you to look at the README in the first git commit, it's very enlightening.
- jogjayr 10y ago
  > Are you suggesting a Git user will eventually need to understand it? That's a strike against Git already. I try to learn about git internals just for the pleasure of it.
- whataretensors 10y ago
  >Are you suggesting a Git user will eventually need to understand it? That's a strike against Git already. I think as engineers we should understand how our tools work.

jlebar 10y ago

$ hg clone https://bitbucket.org/eigen/eigen/ $ cd eigen $ time hg grep CUDA > /dev/null real 0m16.661s user 0m16.097s sys 0m0.531s $ git clone https://github.com/RLovelett/eigen.git $ cd eigen $ time git grep CUDA > /dev/null real 0m0.019s user 0m0.035s sys 0m0.057s Never looked back.

BeetleB 10y ago
This is also why I prefer using C over Python. (End Sarcasm). Seriously? You're so productive that the cost of cloning a repository is a major impediment? The benefits of a cleaner interface mostly trump the benefits of speed.
- jlebar 10y ago
  > Seriously? You're so productive that the cost of cloning a repository is a major impediment? Read the commands more carefully. It is not the cost of cloning the repository, but rather the cost of searching it.
  - BeetleB 10y ago
    Ah. My mistake. 16s is not a big deal, but I'm assuming it would get much worse for larger repositories. Personally, my searches are either: 1. Restricted to all files that end in cpp, h, py, pl, etc. 2. Explicitly exclude .hg directories. I'll confess: I use a nice tool to do my searches than typing it out in grep. Much handier. And it remembers previously used filters (.cpp,.h) and is usually the first item in the drop down box. Much quicker than typing out a grep command. Still, I feel if our team used git instead of hg, we'd lose a lot more time due to people not grokking git and making mistakes than the time lost in longer searches. My point still stands: Things like search time are not a productivity bottleneck. If all our searches were 100x faster, there would be no difference in our output.
    - Jtsummers 10y ago
      16 seconds versus a fraction of a second. There's a big difference, somewhere, in what these two systems are doing to accomplish (ostensibly) the same task. And if it's not accomplishing the same task, they shouldn't be using the same verb (grep) for it. And I disagree with this point: Things like search time are *not* a productivity bottleneck. I maintain old codebases. I don't know them by heart, I didn't write them and the documentation is often poor (for the codebase, the specs are usually decent, but that's the system spec, not the code spec). Search is critical for me to get around these things. A 16s search would be incredibly annoying and bottlenecking compared to one that's nearly instant. Not having looked at the internals of either, I wonder if this is related to other performance differences in grep implementations across *nix systems. EDIT: Exploring this, it seems they don't do the same thing? `git grep` searches, by default, only the most recent working tree or revision. It doesn't search every revision unless you tell it to. `hg grep` (don't have it installed) seems to search every revision by default, so restricting it to the current revision requires an explicit command line option specifying the revision range to search.

marcosdumay 10y ago

Yes, it does 95% of what git does, and very well. The problem, that I don't think anybody even expected, is that there are strong network effects on the selection of your CVS. That gives the tool that can handle more use cases a big advantage, and bigger still if those features are needed on the projects with more developers.

hobarrera 10y ago

Mercurial was a lot harder to understand for me, and had no staging index -- stuff is committed directly. I found that this made it incredibly hard to use, especially coming from git.