Re: git commit -p with file arguments

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 9, 2016, 18:03 UTC
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:

Show 6 quoted lines

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