git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Joan Aguilar <joan.aguilar.lorente@gmail.com>
To: git@vger.kernel.org
Subject: report on a possible bug: git commit -p myfile.py unexpected output
Date: Fri, 24 Mar 2017 11:27:20 +0100	[thread overview]
Message-ID: <CAG+Y4s8m2MqA0yAiZFzv2bAx7g5xktNRb=S-Ej0tvMwU-Un0Og@mail.gmail.com> (raw)

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.

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

             reply	other threads:[~2017-03-24 10:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-24 10:27 Joan Aguilar [this message]
2017-03-24 14:59 ` report on a possible bug: git commit -p myfile.py unexpected output Michael J Gruber
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='CAG+Y4s8m2MqA0yAiZFzv2bAx7g5xktNRb=S-Ej0tvMwU-Un0Og@mail.gmail.com' \
    --to=joan.aguilar.lorente@gmail.com \
    --cc=git@vger.kernel.org \
    /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).