Re: splitting a commit that adds new files

[Jeff King <peff@peff.net>]

On Sun, Feb 02, 2014 at 10:15:07AM -0800, Junio C Hamano wrote:

> Duy Nguyen <pclouds@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" automatically for
> > me so I won't miss changes in "add -p". But maybe people already know
> > how to deal with this case without adding more code?
> 
> Is "reset -p" what you are looking for?  I do not use that myself,
> though.

I don't think so. He is at a commit that needs split, so the first thing
to do is to shift the HEAD back. "reset -p" is only about changing the
index[1]. I suppose you could start with a soft reset, and then "reset
-p" away the changes. But then you are going backwards ("this does not
belong in the commit, remove it" rather than "this does belong in the
commit, add it").

I don't typically have a problem with this because I keep my directory
free of untracked files (they are either marked by .gitignore, or
something that I am planning to commit). So just running "git status"
gives me a neat list of what needs to be added (and typically "git add
-N ." is a good starting point upon which to build a "git add -p"
session).

-Peff

[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".