tibirna / qgit

Official git repository for QGit.
Other
176 stars 70 forks source link

"Amend Commit" incorrectly adds some garbage to the commit message #35

Open tibirna opened 6 years ago

tibirna commented 6 years ago

Submitted by ralfj ralfj on 2017-07-05.

“Amend Commit” incorrectly adds some garbage to the commit message. This can be reproduced as follows:

  1. Go to some git repo with a local change
  2. Choose “Edit” - “Amend Commit”
  3. Don’t touch the commit message, just hit “Ammend”

Now check the new commit message. It is not the same as the old one, instead “on branch ” and some file information has been added. The reason seems to be that qgit does not correctly process the suggested message it gets from git, removing too many “#”. When I use git on the CLI, the lines that qgit adds start with a “#” and are hence ignored by git.

This is a regression, in earlier versions of git + qgit (like, a couple years ago or so), things worked all right.

In case the locale is relevant here: $ env | grep -e LANG -e LC_ LANG=de_DE.utf8 LC_MESSAGES=en_US.utf8 LANGUAGE=en_US:en

tibirna commented 6 years ago

I can't reproduce this. Might there be something else of relevance?

Thanks

wRAR commented 6 years ago

This was also submitted to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787334

negora commented 6 years ago

I'm having exactly the same problem that this user. This error is present in QGit 2.6-1 (from the Debian repository) and QGit 2.8 (from this GitHub repository).

These are the versions used by me:

My language variables look like these:

LANG=en_GB.UTF-8
LANGUAGE=en_GB:en

Just in case, I'm using KDE Plasma 5 as my DE.

The content inserted automatically by QGit, when I amend a commit, is exactly the same text returned by Git when I run git status from the command line.

I've found a workaround, at the cost of loosing important information: If I disable the option Working dir when I open a Git repository, then the action of amending a commit works fine and doesn't add that wrong text.

Maybe this is why some people suffer from this error but others don't? That some people don't enable the Working dir option?

Thank you.

filiperinaldi commented 6 years ago

Hi,

I can see this issue in version 2.5 of QGit as pointed out by the original report (via Debian project) and also version 2.6 as pointed by @negora. I don't see this issue in version 2.8 (@negora you must have run the 2.6 installed in your system after building 2.8. I installed Debian 9.4 on a VM and used 2.8 on it without seeing this issue).

Bisecting the commits, I found out the issue was fixed in c46a6621e585b8a577e9b4bdc52df2a628164add. Line 965 of src/git.cpp seems to be the saviour.

negora commented 6 years ago

@filiperinaldi Hi. When I click on Help -> About QGit the pop-up says QGit version 2.8. I've been using this version for some months. I'm still having this issue.

tibirna commented 6 years ago

I still can't reproduce this, either with 2.8 or with the HEAD. There must be a detail that is different between setups of those see the issue and of those that don't. Any detail you can think of will help.

negora commented 6 years ago

@tibirna At the weekend, I'll try to do some tests in a clean virtual machine. Let's see if I'm able to find a clue. Thanks.

negora commented 6 years ago

Today I've created a new virtual machine in VirtualBox, specifically to test this behaviour of QGit.

I've installed Debian 9.5, using the live CD that includes the KDE Plasma desktop and the non-free drivers. Once that I've ended the installation, I've upgraded all packages to their latest versions.

Then I've installed these packages:

I've cloned the QGit repository, and I've followed the instructions to compile and install it:

/usr/lib/x86_64-linux-gnu/qt5/bin/qmake qgit.pro
make
make install

Finally, I've created a Git repository from the console, have added some files to it and have run QGit 2.8 to commit the changes. The result has been that QGit has shown again that "gargabe" in the message field.

To make sure that it wasn't something specific to the versions of QT5 and Git included in Debian 9, I've done the same test with Kubuntu 18.04.1. Unfortunately, I've got the same result :( .

I've started playing around with the options, and the only way that such "garbage" didn't appear, has been to disable the Working dir option in the dialog that pops-up when I open a repository. However, with such option disabled, I can't make new commits, only amend the text of the last one.

I'll continue making new tests... Out of curiosity, What distros do you use?

negora commented 6 years ago

I think that there has been a misunderstanding on my part. Let me explain...

When I click on Edit -> Commit, I expect that the Commit message field remains empty. But, by default, it contains the same output that appears when I run git commit from the command line: it shows some comments, and you must write your message on top of these.

In the command line, such comments are ignored when you exit the editor. In QGit 2.6, such comments weren't being ignored after clicking on Commit, and ended in the final message. But I've just tested this same thing on version 2.8, and those comments are discarded correctly.

So, Is this last issue what has been fixed in version 2.8? If so, Is it something intentional that the Commit message field shows such comments? Or should this field remain empty?

Thank you!

tibirna commented 6 years ago

The comment is supposed to appear in the "Commit" dialog. The comment should not appear in the final message recorded in the git repo. I tested this both with qgit-2.6 and qgit-2.8 on my local installation (OpenSUSE Leap 15 with git 2.16.4). It can be very clearly read in the code that the comment lines are not even sent to git (see commitimpl.cpp, method CommitImpl::checkMsg()).

negora commented 6 years ago

@tibirna OK. I'm sorry for wasting your time. I thought that the comments shouldn't appear in the Commit dialog either. In that case, I also confirm that the original problem is solved in version 2.8.

I had sworn that it also happened in version 2.6. But I've tried to reproduce the problem again, with that version, and I've been unable. Maybe I saw this error in version 2.5 (from the Kubuntu 16.10 repositories) and, after switching to Debian 9.5, when I saw the comments in the Commit dialog, I thought that the error was still present... Anyway, apologizes for this confusion.