Re: git 1.8.0.rc0.18.gf84667d trouble with "git commit -p file"

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 5, 2012, 22:29 UTC
Message-ID: <7vsj9ssgcp.fsf@alter.siamese.dyndns.org>
In-Reply-To: <op.wlp1lws70aolir@keputer>

"Frans Klaver" <fransklaver@gmail.com> writes:

Show 15 quoted lines

> On Fri, 05 Oct 2012 16:20:45 +0200, Horst H. von Brand
> <vonbrand@inf.utfsm.cl> wrote:
>
>> What I did:
>>
>> - New file images/coins.asy ~~-> 'git add images/coins.asy'
>> - Started adding new stuff to fg.tex
>> - Noticed a old bug in fg.tex, fixed that one
>> - Did 'git -pm "Some message"' and selected just the bugfix
>>
>> But git created a commit _including_ the new file. Tried to go back:
>
> Exactly what's supposed to happen. "git add" tells git you want to add
> the file to the index. The index is what you're going to commit later
> on.

Assuming that the last step of what Horst did was "git commit -pm", I think Git is wrong in this case. When you tell "git commit" what to commit, unless you give "-i" (aka "also") option, the command makes a commit to record changes only from what you tell "git commit" to commit, regardless of what you earlier did to the index.

And choosing what to add via the interactive interface is in the same spirit as telling what to commit to "git commit", so it should behave the same.

This is one of the times I wish I said "No, you cannot have a pony". The change was done without thinking things through, and reviewers including me did not realize this particular downside. My accepting this misfeature (or a poorly implemented feature that has a potential to be useful) was essentially me saying:

    When making a commit that does not match my working tree state,
    I always check with "diff --cached" to make sure what I think I
    am committing matches what I am committing, so I won't use such
    a lazy option myself.  I am not excited to think things through
    to see what possible pitfalls the feature may have for you; I'll
    let you guys hang yourself with that long rope.

And we are seeing a backfire from that "not bothering to think things thorough".

I think the right thing to do is to fix "git commit -p" so that it starts from the HEAD (on a temporary index), just like how partial commits are made with "git commit file1 file2". Or just forbid it when the index does not match HEAD.

Cf.

  http://thread.gmane.org/gmane.comp.version-control.git/173033/focus=173246