[vthriller]

You don't even need to quit editor without saving changes, you can just ^Z it, add new changes, fg the editor back and continue with your commit message.

[u801e]

I actually type my commit messages in a new window in the editor (vim).

  :r !git status -v

Type my commit message above the output, and then visually highlight the lines of my commit message and then run

  :'<,'> !git commit -F -

In fact, if I see an issue with the diff, I can update the relevant file and then run:

  :!git add %

and then go back to the window with the status output, delete it and rerun the status -v command.

In fact, if I want to be more fine grained with the changes I stage in git, I can run:

  :r !git diff

to get the output of the unstaged changes, copy the hunk header lines, paste them above the hunk I want to stage, visually highlight the hunk with the header lines, and then run:

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

to stage that hunk. I've even done things like using recountdiff to update the hunk header if I decide to removed added lines or restore deleted lines in a hunk. Personally, I think it's easier than using git add -p or reset -p.

[yakshaving_jgt]

This is me all the time.

[is writing commit message]

Oh wait… What did I change?

  ^Z
  git diff --cached

Oh yeah.

  fg

[gonzus]

You should be using `git commit -v` then; it will include the full diff of your changes, so you can quickly check them while writing your commit message.

[seemethere]

Yeah this is what I use, the only issue being extraordinarily large commits may get bogged down some times.

I have no idea why anyone would ever not use this to be honest.

[for_xyz]

That workflow seems really slow when dealing with multiple repos/subrepos actively compared to what UI frontends offer.

But it's still more efficient method for single repository project where using UI git client would be the overkill.