W dniu 09.09.2016 o 20:03, Junio C Hamano pisze:
> Jacob Keller <jacob.keller@xxxxxxxxx> 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