6 ms·

Exactly the opposite for me. I absolutely do not trust GUIs to do the right thing. I don't trust text area to use correct line endings consistently across platf

• Groxx 5y ago
  Literally every git GUI I've used has screwed up a git repository at some point, requiring relatively-advanced CLI use to untangle it. They're wildly untrustworthy IMO. They also almost never perform reasonably on truly large repos, aside from gitk. Since using a GUI has inevitably required me to learn CLI in depth, and adds the complexity of figuring out what the hell the GUI actually did because of course it doesn't tell you, I'm basically 100% CLI as well.
  • reificator 5y ago
    I was also in this boat, but vscode has been reliable for me. Maybe I’m not clicking the wrong options, but I used the gut cli exclusively for years so maybe my mental model is in the right place to avoid that.
  • agilob 5y ago
    >Literally every git GUI I've used has screwed up a git repository at some point, I got burnt by this with svn... when unfucking things was a lot more complicated and required faster disk and connection.
  • drainyard 5y ago
    I found this to be true for a long time, but these days you have something like Fork which is much lore user friendly and FAST! We used to use Sourcetree, which is an abomination in comparison. I always use(d) the terminal, but Fork is the first time I am considering using a GUI as my main tool. Granted I haven't had to do anything complicated yet with it, so I don't know if it supports it, but I love it for the basic day-to-day tasks that I do 100's of times a week.
    • Groxx 5y ago
      I'll have to give it a try - I'm not opposed to GUIs, I've just had consistently bad experiences :) And agreed on Sourcetree. It started out promising, but oof. Not any more.
    • dmitriid 5y ago
      Also, GitUp (don't know the state of development now, though). Blazingly fast (but not on big repos with years and years of history), almost everything is done via keyboard shortcuts, allows scenarios like "oh, just mov this commit down, this comit up, squash these two, and re-write the commit message" in 5 seconds tops
    • acherion 5y ago
      Fork is amazing, paid user here. We used to be on SourceTree but found out the hard way that it's a massive CPU hog, especially after being open for a long time (at least on Mac OS).
    • deergomoo 5y ago
      Fork is fantastic, plus it’s nice to have a piece of quality software that doesn’t require a subscription. That said, if they released a new major version I would likely pay for it because I’ve been very happy.
  • stevage 5y ago
    I use GitSavvy. It feels the safest to me because I use the same small set of actions frequently. I fuck things up on the command line much more readily and in ways that I find harder to fix.
  • jesseduffield 5y ago
    One of the largest pieces of feedback I've had is around displaying the actual git commands that lazygit runs so now there's a new panel that does exactly that, displayed by default. I find that works well for demystifying what's going on and can actually help educate on which commands can satisfy which use cases. It's also kept me accountable in that if I try to satisfy some use case in a sneaky, smart way, it results in a scary looking series of git commands, so I've scaled back some of the 'magical' stuff that was going on for the sake of user confidence.
    • canadaduane 5y ago
      What a great idea! Improved confidence + faster learning in a single feature.
    • dotancohen 5y ago
      I always read these "make git easy" threads and I've also written my own "make git easy" wrapper around git. But this comment is the first that has ever given me confidence in actually trying one (by someone else). Nice job.
  • danielvaughn 5y ago
    I use Fork for picking apart which lines I want to commit. It's very cumbersome to commit only specific files and lines using the terminal. I use the terminal for everything else. I would never trust a GUI to do a rebase, not even sure if it's possible with Fork because I've never tried.
    • ggsp 5y ago
      It definitely is, and the UX is quite lovely :)
• flohofwoe 5y ago
  As far as I have seen (I prefer the cmdline myself) Git UIs usually have all sorts of features to select what changes should go into what commits down to single text lines. IMHO this sort of fine grained 'commit management' would be the only reason to use a git UI over what the command line offers.
  • Groxx 5y ago
    `git add -p` does that as well, it's effectively what the GUIs are using. You can also [e]dit each thing and rewrite as desired, though it can be a bit fiddly. UIs can be nicer though for rewriting / making finer-grained splits than the hunks that -p decides on, definitely agreed there. I have broken out a UI just to simplify staging some gnarly commits. GUIs are also often nicer for understanding and resolving nasty three-way merge conflicts.
    • Jaxan 5y ago
      I very much agree to this. I almost always use “git add -p”.
      • Groxx 5y ago
        tbh I think the staging area (and popularizing local branches) may be git's greatest contribution. being able to selectively build a commit is a game-changer for creating understandable histories, and stopping local-tweak "leakage". distributed VCS is neat and all, but the vast, vast majority of cases have a canonical source-of-truth repo somewhere, and the rest are effectively just private mirrors. for those cases, distributed is mostly a significant source of complexity rather than capability. though it is significant to have an "escape hatch" when you need it.
    • agateau 5y ago
      git gui, which comes with git, is quite efficient to do partial commits. I wrote an article about this a few years ago: https://agateau.com/2016/an-intro-to-git-gui/ https://agateau.com/2016/an-intro-to-git-gui/
• reificator 5y ago
  > Does any GUI offer `-p` in `git commit` and `git stash`? I literally use it 10s times per day, can't live without it once I started using it. VSCode’s GUI handles most of what I use -p for, though if I need to use `s` inside -p I drop to the integrated terminal. Not sure if the gui has an equivalent but I haven’t noticed it. Stash on the other hand isn’t missing anything I care about: the gui lets you name stashes if you want, apply latest, etc…
• BoorishBears 5y ago
  The entire point of a GUI is you get the behavior of -p and --dry-run in a much richer context! I've never seen a GUI that doesn't let you very easily select specific lines for commits and I honestly wouldn't use one that didn't. I cannot imagine using git and only being able to push entire files... - And for the record, I use Sublime Merge and it does a great job mapping to terminal commands. Hover over any button and you get the exact git command it will run. It doesn't mess with your tree directly, every action maps to a normal human readable git command. If you want to make a stash with untracked files for example, you just hit the arrow next to "Stash" and get a dropdown with command line args and descriptions for what they do. Sublime Merge will then run it with the exact args you entered, show you the exact CLI command it used, and will show you the exact output. For me Sublime Merge is strictly better than a terminal. I'm comfortable with terminal commands but it's the terminal with a very nice diff view, clean graphs, easier text editing, etc. I never have any ambiguity about what it's going to do.
  • recursive 5y ago
    I cannot imagine using git and having a reason to commit only half a file. I've known it was possible for several years. But never once has it been a solution to any problem I've had. I suppose we both have limited imaginations.
    • BoorishBears 5y ago
      It might be because of the UX around it if you're in the terminal? When it's easy to do you you're more likely to advantage of it.
    • yjftsjthsd-h 5y ago
      I know this is covering a mistake, but I've occasionally done one thing, then done a separate thing without committing (especially easy to do with things like one-line version bumps or super trivial bug fixes), then used git commit -p to commit+push the first change while still working on the second change locally. Obviously this only comes up because I suck at task management, but it is a real-life time when the feature is helpful.
• dceddia 5y ago
  In regards to `-p` -- Lazygit does this. You can press Spacebar to stage individual lines and then partially commit or stash the staged stuff. I like it better than git's built-in `-p` because you don't have to rely on git chunking things up the way you hoped, or spend time splitting git's chunks (hunks?) to get the specific line you wanted to stage.
• bradwood 5y ago
  not quite a "GUI", but lets not forget about vim-fugitive which does all this and a lot more besides.
• eschneider 5y ago
  I'm definitely team command-line for git, but I've been happily using lazygit to quickly review repo changes before committing and it's been pretty good for that.
• ljm 5y ago
  I use magit in emacs and I can create any commit I want by slicing out a bunch of characters in a diff. The git CLI is workable for a lot of things,but the experience of higlighting an arbitrary block of text and saying "commit THIS" has not been matched in any other git UI. We're not talking about hunks or lines here, but literally committing an abitrary range of characters.
  • caseyohara 5y ago
    > committing an abitrary range of characters Honest question: what is the practical use case for this? I'm a fan of small, atomic commits but I don't recall ever wanting to commit just a range of characters.
    • samus 5y ago
      It could be useful for changes in CSV files or text files with table-like formatting where you want to commit the change in just one specific column of a row, but not the other. I could also see it for binary files which aren't structured into lines.
    • ljm 5y ago
      I use it quite a lot to stage a subset of a change, and then drop the rest of it. In that sense, it's like an overpowered undo tool that helps me keep a change I want without having to rewrite the whole thing.
• u801e 5y ago
  I may be in between the GUI and CLI camps. I actually use git via a TUI (text user interface) by using vim to either read from or write to git commands. I can stage hunks by yanking the diff header (excluding the line that starts with @@) and pasting it above the hunk I want to stage and then filtering the hunk through: :'<,'> !git apply --cached - If I want to unstage it, I can press u to restore the hunk I just filtered and then run :'<,'> !git apply -R --cached - I can commit from within vim by reading the verbose status output by running: :r !git status -v typing my commit message at the top and filtering it through :'<,'> !git commit -F - > Does any GUI offer `-p` in `git commit` and `git stash`? I literally use it 10s times per day, can't live without it once I started using it. In addition to what I wrote above using git apply --cached, I can actually edit hunks from within vim and then filter the hunk (with the diff header) through the recountdiff utility that comes with patchutils. That basically updates the numbers in the line that starts with @@ to account for the changes in the number of added and removed lines introduced by the edit. This way, I can stage my changes and still exclude extraneous changes or debug statements I've added to the code. I've actually found this to be a better experience compared to using the -p option.
• gefhfff 5y ago
  Gitkraken has an undo button :)
• smusamashah 5y ago
  IntelliJ allows partial commits really well. Use it all the time. SmartGit also does the same. One problem with intellij UI is that it doesn't let you 'uncheck' line ending change from being staged like it does for individual changes in a file.
• sharperguy 5y ago
  I agree with you, but it does feel strange whenever I do dip into IDEs which have thousands of features built-in to keep you inside the IDE but to then revert back to the command-line to do git stuff. I can imagine for someone who typically uses an IDE, especially if they work on Windows or OSX it would be even weirder.