On Mon, Sep 5, 2016 at 2:08 PM, 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?
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? Thanks, Jake > > 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...". > I guess the part about "git commit files" is different from "git commit -p files", which is confusing. > Thanks, > -- > Christian Neukirchen <chneukirc...@gmail.com> http://chneukirchen.org >
