On Tue, Sep 6, 2016 at 4:08 AM, Christian Neukirchen
<chneukirc...@gmail.com> wrote:
> Hi,
> I noticed the following suprising behavior:
> % git --version
> git version 2.10.0
> % git add bar
> % git status -s
> A  bar
>  M foo
> % git commit -p foo
> [stage a hunk]
> ...
> # Explicit paths specified without -i or -o; assuming --only paths...
> # On branch master
> # Changes to be committed:
> #       new file:   bar
> #       modified:   foo
> #
> So why does it want to commit bar too, when I explicitly wanted to
> commit foo only?
> This is not how "git commit files..." works, and the man page says
>             3.by listing files as arguments to the commit command, in which
>            case the commit will ignore changes staged in the index, and
>            instead record the current content of the listed files (which must
>            already be known to Git);
> I'd expect "git commit -p files..." to work like
> "git add -p files... && git commit files...".

The paths after '-p' could mean two things, either as a filter (e.g.
like in "git add -p") to help save your time going through all changed
files, or as "git commit files...". I think the paths were meant to be
filter when '-p' was added. There's a separate bullet point git-commit
man page, number 5, in about --patch, so that paragraph you quoted is
probably _not_ about --patch. Either way changing its behavior now
might surprise users used to it.

At the least I think we should clarify this in the document. Maybe we
could add --patch-only as well, which commits just what you select in
--patch mode, ignoring anything in existing index.

Reply via email to