From: Jakub Narębski Date: Fri, 09 Sep 2016 20:39:13 GMT Subject: Re: git commit -p with file arguments Message-ID: <23de5ffe-eaf8-2d62-2202-f1bf6087d44b@gmail.com> In-Reply-To: W dniu 09.09.2016 o 20:03, Junio C Hamano pisze: > Jacob Keller 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 " would unstage the bar you >> already added? Or am I missing some assumption here? > > Yes. > > "git commit -p " were added originally for lazy people who > do not want to type "git add -p && git commit", which > matches your expectation. If you already added "bar" that is > outside of the given to "add -p", the final "git commit" > step would record the latest contents of "bar" in it. > > For obvious reasons, "git commit -p " cannot be a > short-hand to "git add -p && git commit ", 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 && git commit would not work as intended, that is it wouldn't create commit out of HEAD and changes to created interactively in the index. "git commit " is a shortcut to "git commit --only "; 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 && git commit ", the "git add -p " would carefully craft the state in the index... and "git commit " would take worktree version of 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:" Best, -- Jakub Narębski