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


[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".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to