From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 09 Sep 2016 18:03:20 GMT
Subject: Re: git commit -p with file arguments
Message-ID: <xmqq8tv1c5nb.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CA+P7+xoN+q_Kst=qXG_HRznxbN7cbyi5uZe15zq1c16EifeK1Q@mail.gmail.com>

Jacob Keller <jacob.keller@gmail.com> writes:

> It wants to commit bar too because you already added bar before. It works like:
>
> "git add bar && git add -p foo && git commit" does it not?
>
> I fail to see why "git commit -p <path>" would unstage the bar you
> already added? Or am I missing some assumption here?

Yes.

"git commit -p <pathspec>" were added originally for lazy people who
do not want to type "git add -p <pathspec> && git commit", which
matches your expectation.  If you already added "bar" that is
outside of the <pathspec> given to "add -p", the final "git commit"
step would record the latest contents of "bar" in it.

For obvious reasons, "git commit -p <pathspec>" cannot be a
short-hand to "git add -p <pathspec> && git commit <pathspec>", so
the current behaviour was the best they could do for those who aded
"commit -p", I guess.