6 ms·

It's not anything inherent to a visual UI though, it's just that most of the UIs that exist are trying to put their own model on top of git, rather than embraci

by dilap 9y ago

It's not anything inherent to a visual UI though, it's just that most of the UIs that exist are trying to put their own model on top of git, rather than embracing git's model. The one exception to this I've found is GitUp (mac only, sadly), and it's excellent. It's whole model is, "what operations can I perform on this graph," which is exactly the model git has. It's great.

dasil003 9y ago
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
- 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.
giancarlostoro 9y ago
SourceTree keeps the same language regular git uses. But I highly agree. JetBrains IDEs add their own lingo out of support for multiple version control plugins I'm sure but its confusing and easy to screw up. SourceTree is the one GUI client I want on Linux...
- ythn 9y ago
  VSCode is the only Git GUI that you need and it's available on Linux
  - Drdrdrq 9y ago
    Do you use it? I have it enabled, but when I tried to revert a few lines (which should be the simplest operation ever - NetBeans did it perfectly; may it rest in peace...) I got some horrific message that made me doubt what the operation will do. So I haven't gathered enough courage to try committing anything... With CLI at least I know what I did wrong.
  - giancarlostoro 9y ago
    VSCode doesn't consistently use git's language afaik, I could be wrong though.
- murukesh_s 9y ago
  This is one time when we wish source tree was written in electron!
Groxx 9y ago
http://gitup.co/ http://gitup.co/ This looks fantastic, thanks for mentioning it! I've been looking for a GUI that doesn't mesh poorly with [whatever patterns my team uses] / without always pushing other features or a signup.
- dilap 9y ago
  It's a really sweet piece of software, and I'm surprised it's not more popular. I'd be curious to hear how it ends up going for ya'll -- you can message me on twitter at @hazememry if you'd like.
  - Groxx 9y ago
    So far I've found: it's reasonably fast until I throw it at a huge monorepo :) but it still works (~2fps)! even `gitk` errors on this one. missing some hotkeys (like prev/next commit buttons in preview) freezes on remote-repo actions like fetch/pull/etc. likely due to our enterprisey ssh setup. generally missing a bit of polish. click targets are small, could use some more config (and only in one location, "search commits" is in its own thing), etc Aside from the remote repo freeze-up, I'm liking it a lot. Way better control than others I've tried (i.e. it has nearly all the features), undo support, and a much better mental-model for Git in general. If I can figure out how to fix the remote freeze-up, it might become my daily driver, which would be a first for a Git GUI.
    - dilap 9y ago
      Yep, doesn't scale great to huge repos, sadly. I hadn't thought about the prev/next preview missing hotkeys, but you're right. I realized what I do is go into preview with space, leave preview with space, and then use the arrow keys to select the next commit I'm interested in. So in effect, "space, down, space" is hotkey for next commit. Bummer about the remote freeze thing. I think the dev is reasonably responsive to bug reports. I've got a list of things myself I think could be better, but I've been too lazy to attempt any of them. But I do try to proselytize in the hopes it'll pick up a bigger community. :-)
  - 9y ago
thomasahle 9y ago
I was in the cli only camp, but I just looked at GitUp and that actually looks really useful!
hyperpallium 9y ago
I'd thought a programming language, for manipulating data structures, would work well... but when I had a go at it, it wasn't as easy to use as I thought. It's because the typical usage patterns aren't simple. A gui with drag-and-drop to rebase a graph also seems like it would work well...

by dilap 9y ago

dasil003 9y ago

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
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.

giancarlostoro 9y ago

SourceTree keeps the same language regular git uses. But I highly agree. JetBrains IDEs add their own lingo out of support for multiple version control plugins I'm sure but its confusing and easy to screw up. SourceTree is the one GUI client I want on Linux...

ythn 9y ago
VSCode is the only Git GUI that you need and it's available on Linux
- Drdrdrq 9y ago
  Do you use it? I have it enabled, but when I tried to revert a few lines (which should be the simplest operation ever - NetBeans did it perfectly; may it rest in peace...) I got some horrific message that made me doubt what the operation will do. So I haven't gathered enough courage to try committing anything... With CLI at least I know what I did wrong.
- giancarlostoro 9y ago
  VSCode doesn't consistently use git's language afaik, I could be wrong though.
murukesh_s 9y ago
This is one time when we wish source tree was written in electron!

Groxx 9y ago

http://gitup.co/ http://gitup.co/ This looks fantastic, thanks for mentioning it! I've been looking for a GUI that doesn't mesh poorly with [whatever patterns my team uses] / without always pushing other features or a signup.

dilap 9y ago
It's a really sweet piece of software, and I'm surprised it's not more popular. I'd be curious to hear how it ends up going for ya'll -- you can message me on twitter at @hazememry if you'd like.
- Groxx 9y ago
  So far I've found: it's reasonably fast until I throw it at a huge monorepo :) but it still works (~2fps)! even `gitk` errors on this one. missing some hotkeys (like prev/next commit buttons in preview) freezes on remote-repo actions like fetch/pull/etc. likely due to our enterprisey ssh setup. generally missing a bit of polish. click targets are small, could use some more config (and only in one location, "search commits" is in its own thing), etc Aside from the remote repo freeze-up, I'm liking it a lot. Way better control than others I've tried (i.e. it has nearly all the features), undo support, and a much better mental-model for Git in general. If I can figure out how to fix the remote freeze-up, it might become my daily driver, which would be a first for a Git GUI.
  - dilap 9y ago
    Yep, doesn't scale great to huge repos, sadly. I hadn't thought about the prev/next preview missing hotkeys, but you're right. I realized what I do is go into preview with space, leave preview with space, and then use the arrow keys to select the next commit I'm interested in. So in effect, "space, down, space" is hotkey for next commit. Bummer about the remote freeze thing. I think the dev is reasonably responsive to bug reports. I've got a list of things myself I think could be better, but I've been too lazy to attempt any of them. But I do try to proselytize in the hopes it'll pick up a bigger community. :-)
- 9y ago

thomasahle 9y ago

I was in the cli only camp, but I just looked at GitUp and that actually looks really useful!

hyperpallium 9y ago

I'd thought a programming language, for manipulating data structures, would work well... but when I had a go at it, it wasn't as easy to use as I thought. It's because the typical usage patterns aren't simple. A gui with drag-and-drop to rebase a graph also seems like it would work well...