Re: git commit -p with file arguments

["Jakub Narębski" <jnareb@gmail.com>]

W dniu 09.09.2016 o 20:03, Junio C Hamano pisze:
> 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.

The 'obvious reasons' are that 

  $ git add -p <pathspec> && git commit <pathspec>

would not work as intended, that is it wouldn't create commit out of
HEAD and changes to <pathspec> created interactively in the index.
"git commit <pathspec>" is a shortcut to "git commit --only <pathspec>";
the git-commit(1) manpage explains (emphasis mine):

 -o
 --only
    Make a commit by taking the updated *working tree contents* of
    the paths specified on the command line, disregarding any contents
    that have been staged for other paths. [...]

Which means that with "git add -p <pathspec> && git commit <pathspec>",
the "git add -p <pathspec>" would carefully craft the <pathspec> state
in the index... and "git commit <pathspec>" would take worktree version
of <pathspec> for commit, ignoring what was in the index :-(

Currently there is no way to create commit out of subset of the index,
e.g. with "git commit :0:<path>"

Best,
-- 
Jakub Narębski