23 ms·

I use the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "

• MonkeyIsNull 9y ago
  > I'm not 100% sure what's going on under the covers. This. A thousand times over. I like to see exactly what git is doing and when; I don't want any magic stuff under the covers done for me.
  • ninkendo 9y ago
    GitHub's GUI is the worst. It has a "sync" button. As soon as I saw that button I knew I'd have trouble using it.. what will "sync" do? Push my branches? Pull tracking branches? Will merge commits get implicitly created? Or will it just fetch? From what servers? I didn't want to risk having my local master get pushed into production just because GH wants to make things easy for me, so I just quit it and went back to the CLI.
    • emodendroket 9y ago
      It just pushes the current branch afaik.
      • michaelmior 9y ago
        So it never pulls updates on the remote? That seems like pretty unexpected behaviour.
        • emodendroket 9y ago
          It pulls and then pushes, I guess I should say, but I was considering "pulls and..." part of the push operation.
      • dotancohen 9y ago
        So they should just call it 'push'. The word 'sync' is not in the Git terminology.
        • emodendroket 9y ago
          The GitHub desktop client is very limited and seems mostly geared toward a lone developer or small team who has never used git before. In this context I think it's a reasonable decision to use a more common verb.
          • craftyguy 9y ago
            Nope. That does no one any good. Using git verbage would, at the very least, acclimate them to very common terminology used by the rest of the folks they will eventually encounter.
            • emodendroket 9y ago
              Well, I disagree, because the alternative for many is probably no source control.
              • craftyguy 9y ago
                Folks writing production crap would opt for no source control? Well, fair enough I guess. But I (and probably most competent sw engineering folks) would never hire someone who was completely oblivious to using source control. So hopefully that 'practice' would die through attrition.
                • emodendroket 9y ago
                  You've got to meet people where they are. Someone who is familiar with how git works is going to find the git GUI client way too limiting to seriously consider using it, whatever verb they use for the push function.
        • aalleavitch 9y ago
    • mchahn 9y ago
      GitHub's Atom editor recently added git operations. I use Atom but haven't had the time to try the git wrapping. Has anyone else used it?
  • pacoverdi 9y ago
    CLI and GUI are both user interfaces and magic is in the eye of the beholder: if you know your tools, you can predict what will happen under the hood when you click on a button as much as when you submit a command (it's not magic anymore). Personally, I use the CLI and often have no idea what I'm doing ;)
  • giancarlostoro 9y ago
    Even GUI based SQL tools show you a log of commands used... Git GUI clients don't even show you beforehand or after what the heck just happened... Sad.
    • tigershark 9y ago
      It's definitely not true. I'm not sure what kind of gui did you use but both sourcetree and gitextensions show you the command log.
      • giancarlostoro 9y ago
        Guess I was wrong, but I never noticed said log. I use SourceTree.
• STRiDEX 9y ago
  I use sourcetree, but I would like a console feature that shows me what commands its running. Similar to sequel pro's "console" feature shows the raw sql being run.
  • ccarse 9y ago
    There's an option in sourcetree, "always show output". This will keep the window that runs the commands open so you can always see what it did and git's output. I always keep this enabled.
  • dilap 9y ago
    the commands themselves are not actually the lowest level, though! (and in fact, are kind of crazily mixed togther; most of the trouble people have w/ git is bad UX for the cli, imo.)
    • Drdrdrq 9y ago
      True. Inconsistent and unintuitive options, oddly named commands (and this is coming from someone who enjoys using Unix clones).
• aldanor 9y ago
  There are GUIs that are very close to CLI that don't try to reinvent a wheel and instead just map directly to what git does. The best one, I think, being Magit for Emacs (if you can call that a 'GUI' given you can run it in the terminal). If you get used to commit things by-line instead of by-file (which is generally highly recommended with git), and also clean up your history/squash things a lot, using git cli gets VERY tedious very fast; I'd rather do it in several keypresses because why not.
  • dilap 9y ago
    Sort of off-topic, but magit isn't really GUI :-) -- though it is very nice, if you're an emacs user. It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.)
    • aldanor 9y ago
      Well. That depends :) I don't develop in Emacs and use it solely for hosting Magit, in a separate window. So it's kind of a GUI I guess; more so than a CLI anyway. > It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.) Don't remember a single of case of it feeling too slow in the last few years, whether on linux/mac... (maybe it just got better over time though)
      • dilap 9y ago
        interesting. i'm on mac; i'll have to give it another try. also we might just have different ideas of "too slow"; for common operations, anything more than instant is basically too slow. :-)
        • tarsius 9y ago
          On macOS it helps to use Emacs 26.1 (unreleased but very solid) or to use a build with a backport of the vfork patch. For more information see https://magit.vc/manual/magit/MacOS-Performance.html https://magit.vc/manual/magit/MacOS-Performance.html. I also plan to make Magit faster across all platforms.
• 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.
        • 9y ago
• Tarean 9y ago
  I like fugitive - it feels like cli git without having to leave the editor. GAdd adds the currently file/selected lines, GBlame pulls up git blame information the ability to reblame, GStatus show the status with the ability to jump to/stage/unstage files and so on. Tried Magit for a while but it didn't play nice with evil. Still hoping for a git repl that just does graph queries/transformations though.
• nerdponx 9y ago
  You might want to try Sourcetree if you haven't already. I felt the same way about Git GUIs for a long time, but Sourcetree actually does a good job of getting out of my way, and has a very nice commit history tree viewer to boot.
  • rsp1984 9y ago
    Actually I find Sourcetree one of the worst git GUIs out there. There are just so many bugs and kinks and glitches in it that I avoid it if possible. I do like the Gitx-dev fork by Rowanj [1]. Clean and simple. Unfortunately just for Mac OS though. [1] https://rowanj.github.io/gitx/ https://rowanj.github.io/gitx/
    • nerdponx 9y ago
      I haven't encountered any of these bugs. But I do use it only rarely, the CLI is where I live most of the time. Good to know about alternatives.
  • sirmarksalot 9y ago
    I've found Sourcetree to be way too slow. My team is currently using the GitFlow model, for various reasons, and that involves switching between branches fairly regularly. It also means that any commit to master involves a lot of steps. From the command line, this isn't a big deal because each of those steps takes a half second or so, but Sourcetree multiplies that by an order of magnitude, and the Sourcetree users are nearing a point of mutiny.
    • tigershark 9y ago
      Source tree is the slowest software that I ever used. Git extensions is much much faster and I never had any performance problem with it.
  • andrepd 9y ago
    Not available for Linux, which is a damn shame.
  • 9y ago
• thelittleone 9y ago
  How about if someone made a GUI with a console at the bottom that showed the commands being executed along with results?
  • mikedelfino 9y ago
    I like typing and I don't think it slows me down too much, so I pass. But it's a good idea.
• CodeMage 9y ago
  The problem, as I see it, is not with the GUIs, it's with the CLI. Just look at the `reset` command: it does several different things, depending on what switches you give it. How would you represent that in a GUI?
• krapp 9y ago
  I use either the GUI on Windows or a set of batch files I wrote to automate basic things. As long as all you're doing is pull, branch, merge and commit, I don't think it matters.
• donarb 9y ago
  XCode rolled out a feature that allowed you to do an interactive commit just by click on/off switches. My first use of that feature screwed up the repo by committing the wrong pieces. No thanks, it’s CLI for me, regardless if the IDE promises git support.
• WhyNotHugo 9y ago
  Same here. Regrettably, if you UNDERSTAND git, a GUI won't work for you. If you're interested in understanding it, it won't work for you either. A GUI works fine if you want to get things done. If you like to know what goes on under the hood, it's just confuse you.
  • electricEmu 9y ago
    I understand git quite well and use a GUI. I was interested in understanding it while using the git. It's pretty sweet that GitExtensions displays the exact command executed. Actually, it made learning vastly easier for the people I taught after myself. Some people do better with GUIs; others the CLI.
  • bseow 9y ago
    I feel this has become a bit of a standard excuse for git. The reason I use a gui isn't because I don't know how git works (while I do forget that too from time to time), but because I can't remember the default behavior and notation of the git cli. I'd be perfectly happy if the cli was actually made to be "low level", but it to a large degree isn't. So if I'm going to have to remember what some abstraction does, it might as well be on a higher level. One example of this is the table at the bottom of this page: https://git-scm.com/blog/2011/07/11/reset.html https://git-scm.com/blog/2011/07/11/reset.html
  • admax88q 9y ago
    The git CLI is horribly inconsistent. http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
• antoaravinth 9y ago
  This is exactly the same reason I too use CLI. But a word of caution Git Bash on windows has some serious problem(s). I remember, I lost my commit and in reflog it doesn't show up on CLI, however GIT UI showed the same! Not sure what's the issue, but it occurred for me twice.
• danmaz74 9y ago
  Some git guis log the git commands they execute. Just look at those.
• nullterminator 9y ago
  I use both. Staging, especially partially staging hunks and lines when doing multiple things at once, is way easier in a GUI when you can scroll around for context and easily undo. For everything else I prefer the command line, because it's faster and I know exactly what is going to happen. I can do what I need to do, no fighting. If I'm just committing everything, I use the CLI. If it's more complicated I use the GUI to stage and commit, and a CLI to rebase/merge/push.