Jeff King p...@peff.net 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.
On Tue, Feb 4, 2014 at 1:11 AM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net 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
Duy Nguyen pclo...@gmail.com writes:
I usually start splitting a commit with reset @^ then add -p back.
The problem is reset @^ does not keep track of new files added in
HEAD, so I often end up forgetting to add new files back (with add
-p). I'm thinking of making reset to do add -N
On Sun, Feb 02, 2014 at 10:15:07AM -0800, Junio C Hamano wrote:
Duy Nguyen pclo...@gmail.com writes:
I usually start splitting a commit with reset @^ then add -p back.
The problem is reset @^ does not keep track of new files added in
HEAD, so I often end up forgetting to add new files
I usually start splitting a commit with reset @^ then add -p back.
The problem is reset @^ does not keep track of new files added in
HEAD, so I often end up forgetting to add new files back (with add
-p). I'm thinking of making reset to do add -N automatically for
me so I won't miss changes in add
5 matches
Mail list logo