On Tue, Feb 4, 2014 at 1:11 AM, Junio C Hamano wrote:
> Jeff King 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
Jeff King 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.
On Sun, Feb 02, 2014 at 10:15:07AM -0800, Junio C Hamano wrote:
> Duy Nguyen 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 (
Duy Nguyen 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" automatical
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 cha
5 matches
Mail list logo