6 ms·

I wonder how much time and money has been wasted trying to operate Git's confusing UI. The repository format itself seems fine, but I'm surprised we're not all

by panic 10y ago

I wonder how much time and money has been wasted trying to operate Git's confusing UI. The repository format itself seems fine, but I'm surprised we're not all using a better frontend by now.

oblio 10y ago
It's the "boil the oceans" problem (http://www.urbandictionary.com/define.php?term=%22boiling%20the%20ocean%22 http://www.urbandictionary.com/define.php?term=%22boiling%20...). Same thing that happens with vi, for example. You have a widely adopted tool with some real or perceived flaws. Everybody knows them and wants to fix them. But unless you somehow get mass adoption from the start, the project flounders because everyone will be pointing out that you can't install & use the new tool in restricted environments or on very old environments. So we're left with the lowest common denominator. At this point, to break the cycle, either the original developers come with the 2.0 interface and push it hard (which might cause backlash: https://xkcd.com/1172/ https://xkcd.com/1172/) or someone with a ton of pull and resources does it from outside (which could trigger a fork or other unpleasantness).
- blakeyrat 10y ago
  Except we all knew how to write better UIs back in 2008 when Git was first written. It's not some brand-new research that only came to light a few years ago. We knew how to do usability tests in 2008. We knew what patterns worked and what didn't. We knew how to build discoverable software. Why the heck wasn't the UI improved back then, before the thing was even released? I mean, while your explanation is correct, it doesn't explain or excuse the pure incompetence of the original developers when it comes to usability issues. Their laziness or ignorance back then has confused and irritated thousands or millions of developers now, and continues to, and will continue to for the foreseeable future. Make sure the shit you're going to set in stone is good before you grab the chisel, guys. You're professional software developers, not clowns. Sorry for the rant.
Cthulhu_ 10y ago
One can argue semantics whether you call it a UI or a CLI, but hey. There's a number of GUI clients out there that depending on your criteria could be considered better. They're usually not as powerful as the CLI client though, and if they are, features like accessing the reflog are hard to find and use. There's also a few alternative CLIs out there, I've just done a quick googling and came across http://www.saintsjd.com/2012/01/a-better-ui-for-git/ http://www.saintsjd.com/2012/01/a-better-ui-for-git/ and http://www.kennethreitz.org/essays/legit-the-sexy-git-cli http://www.kennethreitz.org/essays/legit-the-sexy-git-cli. Personally I prefer the CLI, it's the only tool that I can rely on to do what I tell it to do and to know what's happening. But it takes time and effort to get used to it.
- Normal_gaussian 10y ago
  > One can argue semantics whether you call it a UI or a CLI, but hey. In the same way one can argue whether you call a braeburn a fruit or an apple. CLI is a subset of UI
- deleted 10y ago
  [deleted]
- rck404 10y ago
  I prefer git CLI mostly, except for merge conflicts. Exclusively for git merge conficts I use IDEA IDE resources. Otherwise CLI is my friend because I feel safe (git push and git commit have the best color-coded messages in most OSes)
- blakeyrat 10y ago
  A CLI is a user interface. The problem with Git (well, one of many many problems with Git) is that it conflates its user interface with machine interfaces-- which means tools that have to work with Git (like those GUI clients) have to use the CLI to do so. They don't have a more powerful option, like an officially-supported API or a shared library they could call into. This is terrible software design.
  - niftich 10y ago
minitech 10y ago
The basics (stage, commit, merge, branch, push, pull, log, diff, bisect) aren’t confusing. (The rest isn’t that confusing either, but…) If you prefer GUIs, feel free to use them, but that’s certainly not everyone.
- recursive 10y ago
  I was at least a little confused by stage for a while. I still think the distinction between stage and commit is unnecessary at best.
  - nolemurs 10y ago
    If you don't have `stage` how are you going to generate a commit which has only some of the changes you've done (potentially including partial commits from files)? `stage` is unnecessary if you have a really simple workflow, but it provides a lot of flexibility at very little cognitive cost.
    - recursive 10y ago
      By specifying the parts you want to include when you commit. I think it's unnecessary for any reasonable work flow, and doesn't manage to break even on its benefit vs. cognitive cost.
      - nolemurs 10y ago
        So you want a long command line argument were you tag specific line numbers and have to get it all right at once? That sounds terrible to me. Being able to add bits and pieces to your staging area and then once you've got it all ready commit is pretty useful. I guess I just don't see the cognitive cost as being particularly high. It's a pretty simple model.
        krupan 10y ago
        You can add bits and pieces to commits directly with commit --amend. The index is really not needed.
atsaloli 10y ago
I teach Git. I find many who have learned just enough to get by, and their shallow understanding hobbles them. It's not enough to memorize command line "incantations", you have to understand what's happening. Git is a sophisticated tool. There are over 100 subcommands! Once you fully understand the basic terms (e.g., "detached", "HEAD", "branch", "commit", etc.) Git becomes less confusing. http://www.verticalsysadmin.com/git/flyer.html http://www.verticalsysadmin.com/git/flyer.html describes a free webinar we offer on Git basics -- people who have used Git for years come away surprised how much they've learned.
- grok2 10y ago
  I think you should read back to yourself what you wrote -- you are essentially saying git is complex. Anything complex with enough time and understanding can become easy, but do you need the complexity in the first place? Most developers usually want a simple workflow where they don't want to deal with too many idiosyncrasies of the tool they use. You want to checkin and checkout mostly, but instead one needs to understand a lot of details or you keep tripping up.
  - atsaloli 10y ago
    I understand. Git allows you to do a lot more than check in and check out. It's a powerful tool for collaborating on source code. To the extent that one doesn't confront what Git actually is, it can seem mysterious or needlessly complex. There's a method to the madness. :)
nolemurs 10y ago
Once you understand Git's data model, the UI is perfectly intuitive and very efficient. When you want to do something in git, it generally requires just a single command - you just have to know what you actually want to do. Attempts at different UIs fail because they're all trying to put an abstraction over top of git that doesn't actually reflect the underlying data. As a result, they're limited to the set of git functionality that overlaps their abstraction, and the tools are less powerful.
- StavrosK 10y ago
  This is a good article: https://stevebennett.me/2012/02/24/10-things-i-hate-about-git/ https://stevebennett.me/2012/02/24/10-things-i-hate-about-gi... > Once you understand Git's data model, the UI is perfectly intuitive So it's not intuitive at all. Not to mention that every damn command is inconsistent with every other command! To remove a file, git rm. To remove a branch, git branch -D. To remove a commit, git reset --hard HEAD^. How is this intuitive, consistent, or even sane? "I understand git" and "git is easily understandable" are completely different. Git is not easily understandable, at all.
  - parenthephobia 10y ago
    `git reset` doesn't simply remove commits. Depending upon what you reset to it could result in `git log` showing additional commits, or an entirely different set of commits. Conversely, there's no invocation of `git rm` which creates files. In this case, the commands look different because they do totally different things. You'd have a better argument with `git rm`, `git branch -D` and `git remote remove`. :)
    - StavrosK 10y ago
      Yeah, that was the first thing that popped into my head, but examples certainly abound.
  - nolemurs 10y ago
    I mean, I'll agree, if you insist on trying to create an abstraction to understand git, you can beat your head against the wall for days trying to figure out how it works. On the other hand, if you just take a couple hours to really try to understand what it's doing and why it's not that hard, and it's way more effective and powerful than any other tool out there. Personally I like tools that are powerful and efficient once learned over tools that I can use without any learning. Note that I never said git is easy to learn, just that once you take the time to understand it, it's actually quite natural and intuitive. That article you linked is clearly from someone who liked how simple subversion was and is annoyed that git requires more than 15 minutes to learn. But there's a reason almost no one is using subversion anymore.
tempodox 10y ago
> I'm surprised we're not all using a better frontend by now. Chalk that up to the power of fashion and a misguided notion of technical proficiency.

by panic 10y ago

I wonder how much time and money has been wasted trying to operate Git's confusing UI. The repository format itself seems fine, but I'm surprised we're not all using a better frontend by now.

oblio 10y ago

It's the "boil the oceans" problem (http://www.urbandictionary.com/define.php?term=%22boiling%20the%20ocean%22 http://www.urbandictionary.com/define.php?term=%22boiling%20...). Same thing that happens with vi, for example. You have a widely adopted tool with some real or perceived flaws. Everybody knows them and wants to fix them. But unless you somehow get mass adoption from the start, the project flounders because everyone will be pointing out that you can't install & use the new tool in restricted environments or on very old environments. So we're left with the lowest common denominator. At this point, to break the cycle, either the original developers come with the 2.0 interface and push it hard (which might cause backlash: https://xkcd.com/1172/ https://xkcd.com/1172/) or someone with a ton of pull and resources does it from outside (which could trigger a fork or other unpleasantness).

blakeyrat 10y ago
Except we all knew how to write better UIs back in 2008 when Git was first written. It's not some brand-new research that only came to light a few years ago. We knew how to do usability tests in 2008. We knew what patterns worked and what didn't. We knew how to build discoverable software. Why the heck wasn't the UI improved back then, before the thing was even released? I mean, while your explanation is correct, it doesn't explain or excuse the pure incompetence of the original developers when it comes to usability issues. Their laziness or ignorance back then has confused and irritated thousands or millions of developers now, and continues to, and will continue to for the foreseeable future. Make sure the shit you're going to set in stone is good before you grab the chisel, guys. You're professional software developers, not clowns. Sorry for the rant.

Cthulhu_ 10y ago

One can argue semantics whether you call it a UI or a CLI, but hey. There's a number of GUI clients out there that depending on your criteria could be considered better. They're usually not as powerful as the CLI client though, and if they are, features like accessing the reflog are hard to find and use. There's also a few alternative CLIs out there, I've just done a quick googling and came across http://www.saintsjd.com/2012/01/a-better-ui-for-git/ http://www.saintsjd.com/2012/01/a-better-ui-for-git/ and http://www.kennethreitz.org/essays/legit-the-sexy-git-cli http://www.kennethreitz.org/essays/legit-the-sexy-git-cli. Personally I prefer the CLI, it's the only tool that I can rely on to do what I tell it to do and to know what's happening. But it takes time and effort to get used to it.

Normal_gaussian 10y ago
> One can argue semantics whether you call it a UI or a CLI, but hey. In the same way one can argue whether you call a braeburn a fruit or an apple. CLI is a subset of UI
deleted 10y ago
[deleted]
rck404 10y ago
I prefer git CLI mostly, except for merge conflicts. Exclusively for git merge conficts I use IDEA IDE resources. Otherwise CLI is my friend because I feel safe (git push and git commit have the best color-coded messages in most OSes)
blakeyrat 10y ago
A CLI is a user interface. The problem with Git (well, one of many many problems with Git) is that it conflates its user interface with machine interfaces-- which means tools that have to work with Git (like those GUI clients) have to use the CLI to do so. They don't have a more powerful option, like an officially-supported API or a shared library they could call into. This is terrible software design.
- niftich 10y ago

minitech 10y ago

The basics (stage, commit, merge, branch, push, pull, log, diff, bisect) aren’t confusing. (The rest isn’t that confusing either, but…) If you prefer GUIs, feel free to use them, but that’s certainly not everyone.

recursive 10y ago
I was at least a little confused by stage for a while. I still think the distinction between stage and commit is unnecessary at best.
- nolemurs 10y ago
  If you don't have `stage` how are you going to generate a commit which has only some of the changes you've done (potentially including partial commits from files)? `stage` is unnecessary if you have a really simple workflow, but it provides a lot of flexibility at very little cognitive cost.
  - recursive 10y ago
    By specifying the parts you want to include when you commit. I think it's unnecessary for any reasonable work flow, and doesn't manage to break even on its benefit vs. cognitive cost.
    - nolemurs 10y ago
      So you want a long command line argument were you tag specific line numbers and have to get it all right at once? That sounds terrible to me. Being able to add bits and pieces to your staging area and then once you've got it all ready commit is pretty useful. I guess I just don't see the cognitive cost as being particularly high. It's a pretty simple model.
      - krupan 10y ago
        You can add bits and pieces to commits directly with commit --amend. The index is really not needed.

atsaloli 10y ago

I teach Git. I find many who have learned just enough to get by, and their shallow understanding hobbles them. It's not enough to memorize command line "incantations", you have to understand what's happening. Git is a sophisticated tool. There are over 100 subcommands! Once you fully understand the basic terms (e.g., "detached", "HEAD", "branch", "commit", etc.) Git becomes less confusing. http://www.verticalsysadmin.com/git/flyer.html http://www.verticalsysadmin.com/git/flyer.html describes a free webinar we offer on Git basics -- people who have used Git for years come away surprised how much they've learned.

grok2 10y ago
I think you should read back to yourself what you wrote -- you are essentially saying git is complex. Anything complex with enough time and understanding can become easy, but do you need the complexity in the first place? Most developers usually want a simple workflow where they don't want to deal with too many idiosyncrasies of the tool they use. You want to checkin and checkout mostly, but instead one needs to understand a lot of details or you keep tripping up.
- atsaloli 10y ago
  I understand. Git allows you to do a lot more than check in and check out. It's a powerful tool for collaborating on source code. To the extent that one doesn't confront what Git actually is, it can seem mysterious or needlessly complex. There's a method to the madness. :)

nolemurs 10y ago

Once you understand Git's data model, the UI is perfectly intuitive and very efficient. When you want to do something in git, it generally requires just a single command - you just have to know what you actually want to do. Attempts at different UIs fail because they're all trying to put an abstraction over top of git that doesn't actually reflect the underlying data. As a result, they're limited to the set of git functionality that overlaps their abstraction, and the tools are less powerful.

StavrosK 10y ago
This is a good article: https://stevebennett.me/2012/02/24/10-things-i-hate-about-git/ https://stevebennett.me/2012/02/24/10-things-i-hate-about-gi... > Once you understand Git's data model, the UI is perfectly intuitive So it's not intuitive at all. Not to mention that every damn command is inconsistent with every other command! To remove a file, git rm. To remove a branch, git branch -D. To remove a commit, git reset --hard HEAD^. How is this intuitive, consistent, or even sane? "I understand git" and "git is easily understandable" are completely different. Git is not easily understandable, at all.
- parenthephobia 10y ago
  `git reset` doesn't simply remove commits. Depending upon what you reset to it could result in `git log` showing additional commits, or an entirely different set of commits. Conversely, there's no invocation of `git rm` which creates files. In this case, the commands look different because they do totally different things. You'd have a better argument with `git rm`, `git branch -D` and `git remote remove`. :)
  - StavrosK 10y ago
    Yeah, that was the first thing that popped into my head, but examples certainly abound.
- nolemurs 10y ago
  I mean, I'll agree, if you insist on trying to create an abstraction to understand git, you can beat your head against the wall for days trying to figure out how it works. On the other hand, if you just take a couple hours to really try to understand what it's doing and why it's not that hard, and it's way more effective and powerful than any other tool out there. Personally I like tools that are powerful and efficient once learned over tools that I can use without any learning. Note that I never said git is easy to learn, just that once you take the time to understand it, it's actually quite natural and intuitive. That article you linked is clearly from someone who liked how simple subversion was and is annoyed that git requires more than 15 minutes to learn. But there's a reason almost no one is using subversion anymore.

tempodox 10y ago

> I'm surprised we're not all using a better frontend by now. Chalk that up to the power of fashion and a misguided notion of technical proficiency.