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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Frans Klaver" <fransklaver@xxxxxxxxx> writes:

> On Fri, 05 Oct 2012 16:20:45 +0200, Horst H. von Brand
> <vonbrand@xxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]