On Tue, Sep 6, 2016 at 4:08 AM, Christian Neukirchen <chneukirchen@xxxxxxxxx> 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. -- Duy