git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Michael J Gruber <git@grubix.eu>
To: Joan Aguilar <joan.aguilar.lorente@gmail.com>, git@vger.kernel.org
Subject: Re: report on a possible bug: git commit -p myfile.py unexpected output
Date: Fri, 24 Mar 2017 15:59:07 +0100	[thread overview]
Message-ID: <26915be5-8749-7f66-4d60-516e7ed60adc@grubix.eu> (raw)
In-Reply-To: <CAG+Y4s8m2MqA0yAiZFzv2bAx7g5xktNRb=S-Ej0tvMwU-Un0Og@mail.gmail.com>

Joan Aguilar venit, vidit, dixit 24.03.2017 11:27:
> Hello there
> 
> this is the first bug report of my life and I am not a native English
> speaker so, first of all, I would like to apologize for my English
> skills and the report itself (if it is not precise enough).
> 
> I have already read this 'guidelines'
> http://www.chiark.greenend.org.uk/~sgtatham/bugs.html and I will try
> to attach to them as much as I can.
> 
> What System I am running:
> * Linux 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux
> * git version 2.11.0. Well actually, according to the apt-get install
> output (of course after apt-get update) -> git is already the newest
> version (1:2.11.0-2).
> * VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Feb 13 2017 00:56:16)
> Included patches: 1-197, 322
> 
> What happened:
> I was working on my git repository yesterday and did a lot of changes
> in the file myfile.py. After a little bit of testing I was ready to
> commit them. I decided not to commit all of them at once (because
> these are non related changes), but instead I decided to use the -p
> option (as I always do in this case). For the first patch I decided to
> commit only all methods I have removed because these are not needed
> anymore. So my Idea was to jump from hunk to hunk and split them
> (using 's') to select (with 'y') only the parts I wanted to commit,
> ie, lines I had removed because they are not useful for me anymore. So
> I went for it and I did:
> 
> git commit -p myfile.py
> 
> Until this point all went as expected. The first hunk was printed in
> the console and the it waited for my decision. As always. After a
> couple of hunks I realized it was not possible to split all of them in
> a proper way (to select only removed lines) because new methods were
> mixed up with the old ones. So I cancel the process (ctrl + c) and
> started again using 'e' instead to manually edit the hunks.
> 
> So I repeated the last command: git commit -p myfile.py but this time
> I only used 'y', 'n' and 'e'. All in all I edited ('e') two big hunks.
> By doing this, the default editor (vim in my case) opened showing the
> hunk and with the instructions in how to edit at the bottom.
> Everything as used to be. Until this point all went as I expected.
> 
> In the two hunk I edited I did the same. I removed all + lines by
> deleting them and I make some - lines as context. Like explained in
> the bottom of the file.
> 
> When I was done with each of the hunks, I saved and closed the editor.
> No error was produced (I sometimes make mistakes while editing a hunk
> and know you can get an error (patch does not apply) here, but in this
> case were no errors there so the next hunk was printed and the commit
> procedure kept going.
> 
> When I was done with all hunks, the editor (vim) started again to
> write the commit message. I wrote (something like) this:
> 
>     myfile.py -> old unused methods removed...
> 
>     1) mymethod1
>     2) mymethod2
>     3) mymethod3
>     4) mymethod4
>     5) mymethod5
> 
> Yes, not the best commit ever ;) but enough for us in this case.
> Anyway, I saved it and close the editor and I was surprised by the git
> output.
> 
> [master 96d1c24] myfile.py -> old unused methods removed...
>  1 file changed, 182 insertions(+), 302 deletions(-)
>  rewrite myfile.py (60%)
> 
> What?? I thought to myself... Insertions?? This can't be true? I
> removed all + lines, my idea was to commit only deletions... What did
> I wrong?
> 
> To check this I did
> * git show 96d1c24
> and I saw only red minus lines , ie, deletions. As I expected.

What dows "git show --stat" say?

> To check it twice I used tig too.
> 
> tig showed the same for this specific commit
> myfile.py | 120
> ---------------------------------------------------------------------------------------------------------------------
> 1 file changed, 120 deletions(-)
> 
> Conclusion:
> After these two checks I am sure I did what I intended to do. What I
> do not understand is the output of git when I was done with the
> commit.
> 
> Maybe is just me, because I do not understand how git commit -p when
> using 'e' to edit hunks works. But as user I would expect to see only
> deletions in the output message if I am picking only deletions.
> 
> If this is a bug, I hope you can reproduce it on your system. If not,
> do not hesitate to contact me for further information.
> 
> 
> Kind regards,
> 
> Joan Aguilar
> --
> Joan Aguilar Lorente
> 

182-302 = -120

Did you make any changes in the lines that you left? Apparantly, that's
what the rewrite looked like to git commit.

Michael

  reply	other threads:[~2017-03-24 14:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-24 10:27 report on a possible bug: git commit -p myfile.py unexpected output Joan Aguilar
2017-03-24 14:59 ` Michael J Gruber [this message]
2017-03-24 15:09   ` Jeff King
2017-03-24 15:31     ` Joan Aguilar
2017-03-24 15:52       ` Jeff King

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26915be5-8749-7f66-4d60-516e7ed60adc@grubix.eu \
    --to=git@grubix.eu \
    --cc=git@vger.kernel.org \
    --cc=joan.aguilar.lorente@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).