6 ms·

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.

yakshaving_jgt 6y ago
This is me all the time. [is writing commit message] Oh wait… What did I change? ^Z git diff --cached Oh yeah. fg
- for_xyz 6y ago
  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.
- gonzus 6y ago
  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 6y ago
    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.
u801e 6y ago
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 6y ago

This is me all the time. [is writing commit message] Oh wait… What did I change? ^Z git diff --cached Oh yeah. fg

for_xyz 6y ago
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.
gonzus 6y ago
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 6y ago
  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.

u801e 6y ago

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.