Re: splitting a commit that adds new files

From: Jeff King <peff@peff.net>
Date: Feb 2, 2014, 23:11 UTC
Message-ID: <20140202231110.GC16196@sigill.intra.peff.net>
In-Reply-To: <xmqqzjm9fkk4.fsf@gitster.dls.corp.google.com>

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

Show 11 quoted lines

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