Jeff King [off-list ref] writes:
[1] I _do_ use "reset -p" when splitting commits, but I do not think it
is useful here. I use it for "oops, I staged this change, but it
actually belongs in the next commit. Undo my staging, but leave the
changes in the working tree for the next one".
Sure. I thought that was exactly what Duy was attempting to do when
he splitted a commit into two (or more).
On Tue, Feb 4, 2014 at 1:11 AM, Junio C Hamano [off-list ref] wrote:
Jeff King [off-list ref] writes:
quoted
[1] I _do_ use "reset -p" when splitting commits, but I do not think it
is useful here. I use it for "oops, I staged this change, but it
actually belongs in the next commit. Undo my staging, but leave the
changes in the working tree for the next one".
Sure. I thought that was exactly what Duy was attempting to do when
he splitted a commit into two (or more).
For splitting into two commits, "reset -p" or "reset @^; add -p" would
be more or less the same, although I still prefer to think "this is
what I need" than "this is what I do _not_ need". "add -p" is more
convenient when the commit is big and you need to split into more than
two because the number of revert chunks may be higher than the number
of added chunks. I recall editing a patch with "checkout -p" sometimes
does not work, not sure it happens with "reset -p" too.
--
Duy