6 ms·

I think you've put your finger on the schism of why so many git users prefer a GUI. The built-in porcelain is stupidly inconsistent and confusing. And yet, gi

I think you've put your finger on the schism of why so many git users prefer a GUI. The built-in porcelain is stupidly inconsistent and confusing. And yet, git's underlying model is so simple and powerful that I think it's worth suffering the bad CLI just to be more fluent and able to utilize git's power fully. The model itself is very easy to grok, it just takes some time to memorize the various random incantations and occasionally look something up, but I don't consider that a big deal for a core tool I use every day.

chiefalchemist 9y ago
It might not feelblike that big of a deal, but certainly there has got to be on any given day far more important things you can use those brain cycles for, yes? Low friction or not it's still friction. Friction that can be removed. Yet so many refuse to do so. There's something wrong with this this-is-how-we've-always-do-it picture.
- dasil003 9y ago
  You make it sound like tradition or a cargo cult—it's not. Git is fundamentally better than most of the alternatives, but in my opinion it's misguided to try to slap a better interface over the warts. Rewriting the porcelain would be good, but I don't think it's personally worth investing in until someone makes an attempt that's good enough to get traction and significant mindshare. In the meantime I've already made the investment in learning git and it pretty much stays out of my way.
  - nothrabannosir 9y ago
    > Git is fundamentally better than most of the alternatives No way. Only if you define “good” as “good at the kind of project that git is good at,” where it will hold vacuously. I suffer daily through the cyst that is git LFS, and it’s a joke. It would be funny if it weren’t so tragic. I hear that it’s not doing any better in large scale mono repo land. Google doesn’t use it, afaik. Microsoft does (but multi repo, last I heard), Facebook doesn’t (custom Mercurial, some tasty quotes at [0]). Not a glowing “fundamentally better”, exactly. [0] https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/?_fb_noscript=1 https://code.facebook.com/posts/218678814984400/scaling-merc...
    - dilap 9y ago
      I believe MS has most of windows in a git mono-repo now, enabled by a custom git-supporting filesystem they've developed: https://github.com/Microsoft/GVFS https://github.com/Microsoft/GVFS Pretty cool stuff. Doesn't seem to address the large-files case so much as the many-files case, though. I would love better git support for large files.
    - rhencke 9y ago
      1. Git LFS is not part of Git. It's an unofficial extension, despite the name. I've got my own qualms about Git, but that's like complaining about GitHub's forking model as a reason Git is bad. 2. Microsoft uses Git in single large-scale mono repo form, for - believe it or not - Windows. It clocks in at about 3.5 million files, and a full clone weighs in at 300GB: https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/ https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-large...
      - piyush_soni 9y ago
        Microsoft uses Git in single large-scale mono repo form They had to change git itself to be able to do that. So no, the article itself shows it was not ready for that big a repository.
      - nothrabannosir 9y ago
        Git LFS is not part of Git. That’s my point: without LFS it’s even worse to work with large files. If LFS is the best option you have, forget it. That’s an entire area of projects (anything with assets) you can’t use Git for.
    - dasil003 9y ago
      That's a fair criticism for sure, git makes tradeoffs that fall apart with large repos. You can, however, go a whole career without those things being a problem. Most code repositories are simply not that big.
      - jbergens 9y ago
  - chiefalchemist 9y ago
    Not to sound snarky / adversarial but why is it that (nearly) every article I see on Git has some sort of diagram within it? Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish.
    - chris_wot 9y ago
      The issue is with understanding staging and the working directory. The lightbulb moment for me was reading this article from Atlassian: https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting https://www.atlassian.com/git/tutorials/resetting-checking-o... Understanding that git reset --soft moves HEAD but doesn't change the staged snapshot or working directory, whilst --mixed updates the staged snapshot to match the commit but doesn't touch the working directory was very useful. And knowing that reset --hard updates both staging and the working directory to the commit was where I suddenly "got it".
      - chiefalchemist 9y ago
        Right. And notice all the diagrams. So why use words when pictures better reflect reality?
    - geezerjay 9y ago
      > Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish. It looks like you mindlessly associate a CLI with a poor -- or suboptimal -- user experience. In fact even your choice of weasel words conveys the idea that you want to mindlessly push an irrational belief in spite of not being able to provide arguments to support it. The truth of the matter is that git -- or any other VCS -- operated through commands that change the current state of the repo. The command line interface excels when the user wants to run commands. Any GUI developed for command line tool will end up doing nothing more than replicate what the CLI already does, and will do so poorly.
      - chiefalchemist 9y ago
        Not really. I associate a picture with 1000 words. So if the detailed example/ explanation is an image why isn't the actual process(es) a reflection of that? Put another way, Git is a process that can be rendered pictorially. Words (i.e., CLI) are a less intuitive abstraction. Pardon me for stating the obvious :)
mikedelfino 9y ago
One could also setup aliases for some of the incantations. I personally have `git uncommit` aliased to the proper command line that I never remember.
- donarb 9y ago
  I use aliases for the most common commands, gs, gd, gb, gco, ga, gc. You can guess what those do.
u801e 9y ago
> The built-in porcelain is stupidly inconsistent and confusing. That's why I end up using the plumbing commands to do things that porcelain commands don't let me do directly. For example, I'll use git diff along with git apply and recountdiff (from the patchutils package) to stage individual hunks or edit hunks prior to staging.
euske 9y ago
"C language is so simple and powerful that I think it's worth suffering the bad syntax and memory leak just to be more fluent and be able to utilize the machine's power fully." Pick the right tool for the right job, man. Joking aside, think about the ratio of tasks. Most of the git commands I do is deadly simple. There might be once-in-a-year complex tasks that are more suitable to CLI, but for 99% of the tasks I think GUI could have a net gain in total. Although I'm not a GUI user in this particular case, I'd advocate to use whatever most intuitive to you when possible. Disclaimer: I don't think C syntax is that bad.
- earenndil 9y ago
  It seems like the other way around to me. For 99% of simple tasks, the cli is quick and easy. There are a couple of simple commands, I know and remember them. For the once-a-year complex tasks, maybe I need the gui to be able to more easily and quickly accomplish them.
geezerjay 9y ago
The way you confuse git porcelain with git CLI makes it quite clear that you know nothing about either. I'm yet to find a GUI for any VCS that comes close to doing a job as good as any CLI.
- dasil003 9y ago
  One way to make yourself feel superior to others is to adopt a level of pedantry that only you yourself can meet your own standard. If you then assume everyone around you is ignorant you are not as smart as you think. git porcelain is a CLI. I am well aware that it is only a subset of git's CLI.

chiefalchemist 9y ago

It might not feelblike that big of a deal, but certainly there has got to be on any given day far more important things you can use those brain cycles for, yes? Low friction or not it's still friction. Friction that can be removed. Yet so many refuse to do so. There's something wrong with this this-is-how-we've-always-do-it picture.

dasil003 9y ago
You make it sound like tradition or a cargo cult—it's not. Git is fundamentally better than most of the alternatives, but in my opinion it's misguided to try to slap a better interface over the warts. Rewriting the porcelain would be good, but I don't think it's personally worth investing in until someone makes an attempt that's good enough to get traction and significant mindshare. In the meantime I've already made the investment in learning git and it pretty much stays out of my way.
- nothrabannosir 9y ago
  > Git is fundamentally better than most of the alternatives No way. Only if you define “good” as “good at the kind of project that git is good at,” where it will hold vacuously. I suffer daily through the cyst that is git LFS, and it’s a joke. It would be funny if it weren’t so tragic. I hear that it’s not doing any better in large scale mono repo land. Google doesn’t use it, afaik. Microsoft does (but multi repo, last I heard), Facebook doesn’t (custom Mercurial, some tasty quotes at [0]). Not a glowing “fundamentally better”, exactly. [0] https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/?_fb_noscript=1 https://code.facebook.com/posts/218678814984400/scaling-merc...
  - dilap 9y ago
    I believe MS has most of windows in a git mono-repo now, enabled by a custom git-supporting filesystem they've developed: https://github.com/Microsoft/GVFS https://github.com/Microsoft/GVFS Pretty cool stuff. Doesn't seem to address the large-files case so much as the many-files case, though. I would love better git support for large files.
  - rhencke 9y ago
    1. Git LFS is not part of Git. It's an unofficial extension, despite the name. I've got my own qualms about Git, but that's like complaining about GitHub's forking model as a reason Git is bad. 2. Microsoft uses Git in single large-scale mono repo form, for - believe it or not - Windows. It clocks in at about 3.5 million files, and a full clone weighs in at 300GB: https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/ https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-large...
    - piyush_soni 9y ago
      Microsoft uses Git in single large-scale mono repo form They had to change git itself to be able to do that. So no, the article itself shows it was not ready for that big a repository.
    - nothrabannosir 9y ago
      Git LFS is not part of Git. That’s my point: without LFS it’s even worse to work with large files. If LFS is the best option you have, forget it. That’s an entire area of projects (anything with assets) you can’t use Git for.
  - dasil003 9y ago
    That's a fair criticism for sure, git makes tradeoffs that fall apart with large repos. You can, however, go a whole career without those things being a problem. Most code repositories are simply not that big.
    - jbergens 9y ago
- chiefalchemist 9y ago
  Not to sound snarky / adversarial but why is it that (nearly) every article I see on Git has some sort of diagram within it? Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish.
  - chris_wot 9y ago
    The issue is with understanding staging and the working directory. The lightbulb moment for me was reading this article from Atlassian: https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting https://www.atlassian.com/git/tutorials/resetting-checking-o... Understanding that git reset --soft moves HEAD but doesn't change the staged snapshot or working directory, whilst --mixed updates the staged snapshot to match the commit but doesn't touch the working directory was very useful. And knowing that reset --hard updates both staging and the working directory to the commit was where I suddenly "got it".
    - chiefalchemist 9y ago
      Right. And notice all the diagrams. So why use words when pictures better reflect reality?
  - geezerjay 9y ago
    > Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish. It looks like you mindlessly associate a CLI with a poor -- or suboptimal -- user experience. In fact even your choice of weasel words conveys the idea that you want to mindlessly push an irrational belief in spite of not being able to provide arguments to support it. The truth of the matter is that git -- or any other VCS -- operated through commands that change the current state of the repo. The command line interface excels when the user wants to run commands. Any GUI developed for command line tool will end up doing nothing more than replicate what the CLI already does, and will do so poorly.
    - chiefalchemist 9y ago
      Not really. I associate a picture with 1000 words. So if the detailed example/ explanation is an image why isn't the actual process(es) a reflection of that? Put another way, Git is a process that can be rendered pictorially. Words (i.e., CLI) are a less intuitive abstraction. Pardon me for stating the obvious :)

mikedelfino 9y ago

One could also setup aliases for some of the incantations. I personally have `git uncommit` aliased to the proper command line that I never remember.

donarb 9y ago
I use aliases for the most common commands, gs, gd, gb, gco, ga, gc. You can guess what those do.

u801e 9y ago

> The built-in porcelain is stupidly inconsistent and confusing. That's why I end up using the plumbing commands to do things that porcelain commands don't let me do directly. For example, I'll use git diff along with git apply and recountdiff (from the patchutils package) to stage individual hunks or edit hunks prior to staging.

euske 9y ago

"C language is so simple and powerful that I think it's worth suffering the bad syntax and memory leak just to be more fluent and be able to utilize the machine's power fully." Pick the right tool for the right job, man. Joking aside, think about the ratio of tasks. Most of the git commands I do is deadly simple. There might be once-in-a-year complex tasks that are more suitable to CLI, but for 99% of the tasks I think GUI could have a net gain in total. Although I'm not a GUI user in this particular case, I'd advocate to use whatever most intuitive to you when possible. Disclaimer: I don't think C syntax is that bad.

earenndil 9y ago
It seems like the other way around to me. For 99% of simple tasks, the cli is quick and easy. There are a couple of simple commands, I know and remember them. For the once-a-year complex tasks, maybe I need the gui to be able to more easily and quickly accomplish them.

geezerjay 9y ago

The way you confuse git porcelain with git CLI makes it quite clear that you know nothing about either. I'm yet to find a GUI for any VCS that comes close to doing a job as good as any CLI.

dasil003 9y ago
One way to make yourself feel superior to others is to adopt a level of pedantry that only you yourself can meet your own standard. If you then assume everyone around you is ignorant you are not as smart as you think. git porcelain is a CLI. I am well aware that it is only a subset of git's CLI.