Hacker News Reader

Comment by smichel17 | Hacker News Reader

I like staging my changes with `git add -p` before I commit as a way of reviewing what I did. I often catch mistakes or unnecessary changes this way. I suppose you could build the same workflow with stashes, but it seems quite awkward that way.

View on HN

git add -p is extremely useful if I encounter a typo or something while doing some other change. Then I can commit this small unrelated change in its own commit without mixing with actual changes and without losing my context (of course this should be trivial stuff only, as it might be mixed up in the feature branch of current work)

I just review the diff before I commit.

I do the same thing for small commits. Anything larger than ~25 lines (to the point where the whole diff doesn't fit on screen at once) becomes a lot of wasted time finding where I left off. Adding things incrementally means I don't need to look at them twice.

I rarely use git add (basically only for new files or non-text files) and instead always use commit --patch.

What do you do when you come across lines that you want to commit, but edit beforehand? I always run into syntax errors when I use `e` to edit a diff during `git add -p`, and it doesn't update the file in the working tree, which I also want. Skip it and then `commit --amend`?

A tiny change like a typo in a comment I would just edit in both the git commit --patch `e` editor and in the working tree copy. Anything bigger I'd either abort or skip and edit/test normally and then amend. My main use for `e` are not really edits to the final code but rather for splitting up changes that affect the same line.

I only had problems with errors from `e` on Windows - I'm guessing due to wrong line endings.

TIL about this. I was using `git add -i` and using the patch function.

Reply on news.ycombinator.com