Duy Nguyen <pclouds@xxxxxxxxx> writes:
>> +$ git reset -p HEAD^ <1>
>
> For good practice, perhaps put "git diff --cached HEAD^" before "git commit".
>
> I tend to avoid "reset -p" and "checkout -p" though because sometimes
> it does not work. Not sure if it's just me, I think it may have
> something to do with splitting hunks. So I usually go with "reset
> HEAD^" then "add -p" and "commit -c HEAD@{1}" instead.
Perhaps I am superstitious, but I do that, too.
Doing this that way, the users do not need to learn "reset -p" or
"checkout -p" and only need to know "add -p", and not having to
learn two extra things is a big plus. On the other hand, it
requires the users to learn the reflog, but that knowledge extends
to the use outside of the -c option of "commit" command, so overall
I think it is a win.
>> +$ git commit --amend <2>
>> +$ git commit ... <3>
>> +------------
>> ++
>> +<1> This lets you interactively undo changes between HEAD^ and HEAD, so you can
>> + select which parts to remove from the initial commit. The changes are
>> + placed into the index, leaving the working tree untouched.
>> +<2> Now, you ammend the initial commit with the modifications that you just
>
> s/ammend/amend/
>
>> + made in the index.
>> +<3> Finally, you can add and then commit the final original unmodified files
>> + back as the second commit, enabling you to logically separate a commit
>> + into a sequence of two commits instead.