6 ms·

Somebody proposed to use a GUI. That doesn't solve the usability issues of Git. There's this triangle of what the user tries to do, what the commands and option

by dep_b 10y ago

Somebody proposed to use a GUI. That doesn't solve the usability issues of Git. There's this triangle of what the user tries to do, what the commands and options are called and what they actually do. None of them really align, though with some careful use you can actually make Git do what you want - eventually. I would like to understand what's the yearly damage of such an important tool being so difficult to use. People committing the wrong stuff, unmergeable messes, people not being able to correct their mistakes, there must be thousands of Git rookies fucking up their Git repo or throwing away their work just as I am writing this. What would be the cost? Millions of Dollars? Perhaps even billions? It's about as bad as 0 being a legit value for a regular pointer.

overgard 10y ago
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.
nhaehnle 10y ago
People complain, but what's the alternative? Non-distributed VCS clearly don't cut it for many use cases, and of the other DVCS I've tried, none were really better than Git in my opinion. Sure, it depends on your workflow. But if part of your workflow is authoring sequences of commits that make sense in hindsight, then I honestly haven't seen an alternative. The point of Git is that it gets the underlying data model right, and just exposes that. Once you grok that, it is superior to everything else. If you don't grok it, you have a problem. For this reason, I think GUIs are actually somewhat detrimental for Git use. git gui and gitk serve a purpose, and they could definitely need some polish, but my other explorations into Git GUIs have basically turned out to be badly done and leaky abstractions which hurt more than they help.
- ufmace 10y ago
  I like Git generally, and my feelings on GUIs for it are kinda mixed. I like GUIs for visualizing the log with all branches, and they make it easier to selectively commit some of your changes, especially partial files. I haven't seen any that are much help over the command line for managing branching and merging, though. I like GitX for OS X because it does the things that I think GUIs are good at, and doesn't try to do much else.
- Chromozon 10y ago
  Many large companies use Perforce. Its UI is great. It's very easy to learn, so the cost of teaching new employees is low. It's hard to screw up, and when you do screw up, it doesn't require an expert to come in and fix things with obscure commands.
  - nhaehnle 10y ago
    I'm genuinely curious if this isn't an effect of biased in favour of what you know (on both sides, possibly). I found Perforce to be terribly opaque. Perhaps this is because the good stuff is buried amidst enterprise nonsense, but compare the experience of going to git-scm.com versus perforce.com if your goal is to learn. (Not to mention the fact that Perforce as I know it simply doesn't cover the distributed use cases that Git does. Obviously adding distributed features makes any VCS more complex, but that is the inherent complexity of the problem space as opposed to artificial complexity. If your problem is conceptually easier, you can make the solution appear easier.)
chousuke 10y ago
I feel like people's opinion of git's usability is lower than what it actually is. Certainly, it's got a lot of different switches and stuff, but since its data model is so simple, you can always understand what it's doing to your data. So you can read a description of what a switch does, and then understand exactly what will happen when you use it. (The exception to this is automatic merge conflict resolution with rerere, which is just magic to me. But it's a bonus feature anyway) For me, as a long time git user, git's UI and UX is approximately a bajillion times better than something like SVN, which can barely even do half the things that I use every day in git. Maybe I haven't just dug deep enough into Subversion's manual, but can you tell me how to do the equivalent of "git log -p"? Last time I checked (SVN 1.8) that's not very trivial. Or how to revert a commit? IIRC that requires a merge. So at least compared to subversion, git enables a workflow that was previously too much work, and gives me a better tool for working with version-controlled text data. Mercurial is another thing I find puzzling, and I'm honestly interested why it is that people find it so much easier to use than git. I'm so used to working with throw-away branches that hg's default branching model just feels needlessly difficult to me, and good support for managing branches is the most important feature of a VCS, since any change you ever make is automatically a branch from the base. In git, this feels natural, since branches are a feature of the underlying data model, not something treated specially.
- Nemcue 10y ago
  Except very few actually take the time to understand the data model..
- RJIb8RBYxzAMX9u 10y ago
  > [C]an you tell me how to do the equivalent of "git log -p"? Last time I checked (SVN 1.8) that's not very trivial. svn log --diff, added in 1.9. Also doable with a little (est. < 10 lines) of shell scripting. > Or how to revert a commit? IIRC that requires a merge. git and svn disagree on whether history should be permanent or not.

by dep_b 10y ago

overgard 10y ago

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.

nhaehnle 10y ago

People complain, but what's the alternative? Non-distributed VCS clearly don't cut it for many use cases, and of the other DVCS I've tried, none were really better than Git in my opinion. Sure, it depends on your workflow. But if part of your workflow is authoring sequences of commits that make sense in hindsight, then I honestly haven't seen an alternative. The point of Git is that it gets the underlying data model right, and just exposes that. Once you grok that, it is superior to everything else. If you don't grok it, you have a problem. For this reason, I think GUIs are actually somewhat detrimental for Git use. git gui and gitk serve a purpose, and they could definitely need some polish, but my other explorations into Git GUIs have basically turned out to be badly done and leaky abstractions which hurt more than they help.

ufmace 10y ago
I like Git generally, and my feelings on GUIs for it are kinda mixed. I like GUIs for visualizing the log with all branches, and they make it easier to selectively commit some of your changes, especially partial files. I haven't seen any that are much help over the command line for managing branching and merging, though. I like GitX for OS X because it does the things that I think GUIs are good at, and doesn't try to do much else.
Chromozon 10y ago
Many large companies use Perforce. Its UI is great. It's very easy to learn, so the cost of teaching new employees is low. It's hard to screw up, and when you do screw up, it doesn't require an expert to come in and fix things with obscure commands.
- nhaehnle 10y ago
  I'm genuinely curious if this isn't an effect of biased in favour of what you know (on both sides, possibly). I found Perforce to be terribly opaque. Perhaps this is because the good stuff is buried amidst enterprise nonsense, but compare the experience of going to git-scm.com versus perforce.com if your goal is to learn. (Not to mention the fact that Perforce as I know it simply doesn't cover the distributed use cases that Git does. Obviously adding distributed features makes any VCS more complex, but that is the inherent complexity of the problem space as opposed to artificial complexity. If your problem is conceptually easier, you can make the solution appear easier.)

chousuke 10y ago

I feel like people's opinion of git's usability is lower than what it actually is. Certainly, it's got a lot of different switches and stuff, but since its data model is so simple, you can always understand what it's doing to your data. So you can read a description of what a switch does, and then understand exactly what will happen when you use it. (The exception to this is automatic merge conflict resolution with rerere, which is just magic to me. But it's a bonus feature anyway) For me, as a long time git user, git's UI and UX is approximately a bajillion times better than something like SVN, which can barely even do half the things that I use every day in git. Maybe I haven't just dug deep enough into Subversion's manual, but can you tell me how to do the equivalent of "git log -p"? Last time I checked (SVN 1.8) that's not very trivial. Or how to revert a commit? IIRC that requires a merge. So at least compared to subversion, git enables a workflow that was previously too much work, and gives me a better tool for working with version-controlled text data. Mercurial is another thing I find puzzling, and I'm honestly interested why it is that people find it so much easier to use than git. I'm so used to working with throw-away branches that hg's default branching model just feels needlessly difficult to me, and good support for managing branches is the most important feature of a VCS, since any change you ever make is automatically a branch from the base. In git, this feels natural, since branches are a feature of the underlying data model, not something treated specially.

Nemcue 10y ago
Except very few actually take the time to understand the data model..
RJIb8RBYxzAMX9u 10y ago
> [C]an you tell me how to do the equivalent of "git log -p"? Last time I checked (SVN 1.8) that's not very trivial. svn log --diff, added in 1.9. Also doable with a little (est. < 10 lines) of shell scripting. > Or how to revert a commit? IIRC that requires a merge. git and svn disagree on whether history should be permanent or not.