Re: [PATCH] reset: add an example of how to split a commit into two

Duy Nguyen [off-list ref] writes:

quoted

+$ 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.

quoted

+$ 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/

quoted

+    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.

On Fri, Feb 3, 2017 at 10:59 AM, Junio C Hamano [off-list ref] wrote:

Duy Nguyen [off-list ref] writes:

quoted

quoted

+$ 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.

I didn't know about the "-c" option to git commit, that makes the add
-p path a bit more straight forward. I'll re-word the example to use
this new suggested flow.

Thanks,
Jake