← Back to context

Comment by dilap

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

36 comments

dilap

Reply
dasil003  7 years 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.

  • euske  7 years 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  7 years 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.

  • chiefalchemist  7 years 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  7 years 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.

      12 replies →

  • u801e  7 years 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.

  • mikedelfino  7 years 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  7 years ago

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

  • geezerjay  7 years 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  7 years 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  7 years 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  7 years ago

    VSCode is the only Git GUI that you need and it's available on Linux

    • Drdrdrq  7 years 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.

Groxx  7 years ago

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.

  • benliong78  7 years ago

    Thanks for the recommendation. Fantastic looking software that provides a far better visualization of the repo than anything else I have used. Bravo.

    I use CLI for almost everything but sometimes it helps to have a visual representation of the repo.

  • dilap  7 years 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  7 years 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.

      1 reply →

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