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.
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.
I got burnt by this with svn... when unfucking things was a lot more complicated and required faster disk and connection.
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.
And agreed on Sourcetree. It started out promising, but oof. Not any more.
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.
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.
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.
I repeatedly run into this using the interactive features.
but for me a bigger reason to prefer a git UI is that I can actually see the graph. I can do things like drag branches between commit nodes. I find this so much easier and safer than the cli
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…
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.
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.
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.
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.
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 -
:'<,'> !git apply -R --cached -
:r !git status -v
:'<,'> !git commit -F -
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.
The command line isn't some mystical scary thing, it's a extremely effective method of controlling a computer. It's survived this long for a reason, and it's not going to go anywhere. It's powerful, and extremely simple. Children learn how to use it every day (nerdy children, but still).
Try spending a few hours over the weekend actually trying to learn it. If you do, you'll see how it's a lot easier than you thought, and saying that you're "terrified" of it is silly.
For some things, definitely not for doing a 3 way merge.
if you know the bare basics of emacs(like a few file commands and how to exit), magit and vim that is a huge productivity win. magit is simply the finest complete git gui that does most things seamlessly.
simple workflow
in the project dir
$ emacs
spc-g-g to enter magit
? shows help(and every command pops up a menu with options)
j/k to navigate lines up and down
s and u to stage and unstage chunks of text/files/lines
x to delete something
cc to initiate a commit
edit the commit message
ctrl-c ctrl-c commit.
ctrl-c ctrl-c abort commit
q or escape goes back a "page" like from viewing the log to go back to the staging area
the trick is everything follows that basic form where [a-zA-Z] starts a command, pops up a menu and shows the next options but the general trend is that it usually is the same two letters. bb is checkout a branch and it usually pre-populates the thing you are on if that is applicable. ll is log this branch. la is log all branches and everything in the log is interactive.
it's pretty magical.
doesn't work well with vim plugins... need to go to insert mode to actually interact with it (might be configurable and fixable)
stuff that takes one keystroke on magit is clunkier in gitsavvy. tab in magit expands short diffs from the main status page where you can stage or unstage selections or get an overview of the changes. l to "inline diff" opens a diff in a new file whereas tab just opens and closes sections on the main dashboard. ctrl-jk move from chunk to chunk. enter opens the file to edit or more generally does an action like view the commit under the cursor if you are in a the log graph and q will "quit" out and pop the interaction back to the log graph.
it's hard to overstate just how well everything flows in magit and i've never heard anyone say anything bad about it other than something like I wish it wasn't tied to emacs. simply the best and most well thought out piece of software i've used.
edit: i'm just scratching the surface on what magit can do... literally everything is possible through the interface even one off git commands but almost everything is very easy and interactive from any point in the interface
There's also hub, from GitHub. I find myself using "hub sync" to update all my local branches at once.
> I just can't get cozy with doing a lot of heavy lifting in any shell environment
I've argued that undergrads should spend their first year (or first semester) almost exclusively on the terminal/in the shell. Sure it makes some operations cumbersome but after you get over the learning curve the returns are spectacular.
A unicycle can also be better than a car. Doesn't mean anyone should ever choose a unicycle over a car (unless you're a clown I guess)