> Using a UI makes it easy to review your changes before you commit them, there’s no way you can review (and pick or discard) your 100-lines 5-files changes effectively on the command line.

Sorry, what? A command line IS a UI. And it happens to be great for displaying text, like what is displayed with git diff...

I mean GUI, a clickable interface with columns and such. With a CLI you get all the files in a single scrollable area.

Side note: there are also GUIs for the terminal, they’re fine.

I actually use the git cli by filtering text to various command std input using vim. So, for staging diffs, I'll read the output of git diff, and hand edit the diff as needed, and stage individual hunks by filtering the text through the git apply command with the appropriate parameters.

I can then run git status -v to show what's currently staged, write the commit message and filter it through the git commit command.

> there’s no way you can review (and pick or discard) your 100-lines 5-files changes effectively on the command line.

It's easy enough to find the approriate hunk and edit the diff to stage what's needed. I may go through the process a few times to create a single commit depending on how many hunks I have to deal with and how many times I need to split them though.

In fact, my normal workflow is to make the necessary changes for a particular feature I'm working on, take the diff against the base branch and then stage parts of that diff to create a series of sensible commits for the branch.

I would really like to see this workflow. Are there any articles, videos, or asciinemia recordings of how this is done?

I don't know of any, but the key thing to know is how to edit diffs manually. If you've ever run git add or reset with the -p parameter, you may have noticed an option where you can manually edit a diff hunk. If you choose that option, it describes several rules for editing hunks:

1. Remove lines beginning with + to keep them from being added

2. Replace the beginning - with <space> for lines to keep them from being removed

But you can go further with this by adding more lines beginning with + to add lines that weren't in the original hunk, or add a - prefix to a context line (beginning with a <space>) to remove it. You can even modify the content of lines prefixed with + (i.e., to fix a syntax error you noticed) before staging them.

The other thing to note is the surrounding context lines for a given hunk. Ideally, you have at least 3 lines before and 3 lines after the hunk to ensure that when it's applied, it changes the file in the correct location.

In order to actually stage a hunk, you need to add the necessary header lines above the line that begins with @@. These lines are the ones that begin with diff, index, ---, and +++. For the first, third and fourth lines, the path and file name need to match the file you intend to apply the patch to.

When you're ready to stage your edited hunk, you just visually highlight it in vim (shift-v) and then run

    :'<,'> !git apply --cached --recount

The --cached option prevents git from trying to modify the file in the working tree and limits it to just modifying what's in the git index. The --recount option basially makes it easier to apply an edited patch by not really looking at the line that begins with @@. If your patch applies, you can view how it looks like in the index by running

    git status -v

or

    git diff --cached

You can even view the file as it is in the git index by running

    git show :0:path/to/file

I use the git cli exclusively. The reason for it was Sourcetree. I started with git in 2010 coming from svn and had a hard time to wrap my head around the basic concepts of staging, commit and push etc. I used sourcetree and the docs and was very confused with the UI because it sometimes contradicted the understandings I got from the docs. So started using it from the cli and never switched back. In the beginning I used the ‘-i’ flag for the ‘git add’ a lot to filter out what files to stage etc. This was mainly because I worked in an unfamiliar project and wasn’t able to write out file paths from memory.

That has changed over the years. I use a few custom created aliases + specific Workflows how I go about making changes to a project.

I’m not interested in any of the fancy git UIs (sourcetree, tower, fork, kraken) because each tries to simplify git and or would break my workflow. For instance I don’t use Explorer, Finder etc to traverse files. I open a new terminal session and cd through my file system. I have a strict setup which I replicate on the different machines/VMs I use so I know it from memory. I don’t need to switch to a UI tool that knows where all my checkouts are and klick a terminal button to start a session there. I work from the terminal and open Idea, VSCode or vim from the project. The latter is the reason I could not adopt eMacs as it didn’t really work well for me with this kind of workflow.

And last. I stopped doing multiple fancy changes all at once in a project that would warrant the use of specialized tools or UIs. If I see that a change gets out of hand I start to formulate base batches on the go. I can create a series of commits and split them up/rebase afterwards.

But I don’t Stopp anyone from doing it differently. We are all wired differently and use the given tools how we feel best.

Ah also working with a lot of remote headless machines it is nice if you know you way around the cli in general. Or my favorite issue I had the last couple of weeks switching from Nvidia to AMD (X-Server did not start) issues ;) No ui to help to fix this.

Git CLI user here. I started out using Sourcetree about 10 years ago and have slowly moved everything into the terminal after also using many other GUIs. `git add -p` was the last thing to move to terminal because it can be hard to stage individual lines in hunks that can’t be automatically split.

But after I picked up emacs again and started using magit even that became a breeze.

Also, for reviewing changes, I use the no context option `git diff -U0`and more recently use git-delta for better color highlighting and the side-by-side diff view.

I also think in addition to just having learned and practiced over a decade, the way I’ve used Git has evolved too. I keep PRs small and cohesive, always squash all their commits, and because of that I don’t have to care so much about untangling cohesive changes at commit time, although I also don’t let them pile up. I usually do a lot of `git commit --amend` and `git commit --fixup` (more and more rarely actually followed by a `git rebase --autosquash` since the PR takes care of the squash now… I don’t even have to worry about order-based conflicts anymore).

I didn't know about git delta, thanks for this. Presumably your referring to https://github.com/dandavison/delta ?

Does anyone have any tips for integrating it into an emacs workflow? I'm currently doing `git commit` from shell which launches emacs-nox with magit.

Hmm, I haven't heard of delta before. I've been using diff-so-fancy for a while ( https://github.com/so-fancy/diff-so-fancy), but I might have to give delta a try.

Edit: It looks like this page shows the comparison between delta and diff-so-fancy: https://dandavison.github.io/delta/features.html

I would say vim-fugitive is great for this.