From: Junio C Hamano <gitster@pobox.com>
To: "Frans Klaver" <fransklaver@gmail.com>
Cc: git@vger.kernel.org, "Horst H. von Brand" <vonbrand@inf.utfsm.cl>,
Jeff King <peff@peff.net>, Conrad Irwin <conrad.irwin@gmail.com>
Subject: Re: git 1.8.0.rc0.18.gf84667d trouble with "git commit -p file"
Date: Fri, 05 Oct 2012 15:29:10 -0700 [thread overview]
Message-ID: <7vsj9ssgcp.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <op.wlp1lws70aolir@keputer> (Frans Klaver's message of "Fri, 05 Oct 2012 21:55:07 +0200")
"Frans Klaver" <fransklaver@gmail.com> writes:
> 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
next prev parent reply other threads:[~2012-10-05 22:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-05 14:20 git 1.8.0.rc0.18.gf84667d trouble with "git commit -p file" Horst H. von Brand
2012-10-05 19:55 ` Frans Klaver
2012-10-05 22:29 ` Junio C Hamano [this message]
2012-10-05 22:57 ` Jeff King
2012-10-06 6:26 ` Junio C Hamano
2012-10-06 13:12 ` Jeff King
2012-10-06 18:22 ` Junio C Hamano
2012-10-06 18:30 ` Jeff King
2012-10-06 18:32 ` Conrad Irwin
2012-10-06 19:07 ` Jeff King
2012-10-07 20:51 ` Junio C Hamano
2012-10-07 21:49 ` Jeff King
2012-10-07 22:23 ` Junio C Hamano
2012-10-07 22:25 ` Jeff King
2012-10-11 5:51 ` Conrad Irwin
2012-10-11 17:57 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vsj9ssgcp.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=conrad.irwin@gmail.com \
--cc=fransklaver@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=vonbrand@inf.utfsm.cl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).