tibirna / qgit Goto Github PK

Size of labels for branches and tags should be limited to a maximum and expandable on request.

When many branches+tags exist on the same revision, offer an optional compressed view (only an indicator of the number of labels) and an optional full view (expanding the QTableRowItem to the necessary height).

It would be great to have an option to enable/disable automatic line breaking/word wrapping in the patch/diff window.

When the first commit is selected, qgit does not show the diff content.

"External Diff" allows opening an external app with the modifications applied to current selected file in a commit. "External Editor" allows opening an external app with the currently selected file (either in the file tree view or in a commit file list).

These actions are always active when a file is selected, either in the file tree view or in a commit file list view. If the file tree view is collapsed and there is no selection in the current commit's file list view, both these actions remain active and it is not clear from the context why. Furthermore, the "External Diff", when invoked, will open with an empty diff (because the hidden selected file in the file tree view has no diff context attached to it).

TODO: deactivate "External Diff" and "External Editor" actions when the file tree view is not visible. Deactivate the "External Diff" action when the selected file has no diff context (is not selected as part of a commit).

QGit started to behave in a weird manner lately yielding strange and incorrect output, and often crash when retrieving the repository log information. This seems to be caused by my ~/.gitconfig which instructs git log to show GPG signatures by default. I think QGit needs to pass --no-show-signatures or similar to git log, or properly parse the signature information contained in the log.

Here's the relevant part of my ~/.gitconfig:

[log]
    showSignature = true

Submitted by Mario Blättermann on 2014-02-21:

currently QGit seems to don’t have any command line options. It is impossible to submit a folder name (which contains a Git repo). QGit will always opened with an empty view. It should be possible to type the following:

[mariobl@localhost Debian-Git]$ qgit ./manpages-de

All it needs is the appropriate command line option to open folders and the associated *.desktop file which is for the file manager’s context menu.

I’m using Fedora 20 x86_64 with QGit v2.5.

Submitted by Andrey Rahmatullin on 2017-07-04.

Currently Ctrl-C is a shortcut for the Checkout dialog which is unexpected and inconvenient. Please replace with something else.

If the cache file (.git/qgit_cache.dat) gets corrupted in some way (e.g. file truncated or crash in the middle of saving it), qgit can't be started anymore on the affected repository, crashing in the cache reading process.

TODO: wrap all cache process in a try...catch... and simply reconstruct cache on any error. If recovery process fails, forego use of cache and inform user for further investigation.

Related issue: #69

Submitted by Michael Gerdau on 2017-04-18.

Description: Filenames sporting utf-8 characters are not displayed correctly. E.g. a file named (without the '“') “Abendstille-überall.ly” is displayed as “Abendstille-\303\274berall.ly”. UTF-8 is the selected character set whereever it can be configured in qgit, i.e. Settings, “General” tab field “Text codec” as well as in “Git config” tab Parameter “i18n > commitencoding” are all set to UTF-8.

Additional info:
package version(s): at least since 2.5; it definitely is in the current 2.7
Steps to reproduce:
the default encoding of the filesystem is UTF-8
in a git repository viewed with qgit create a file with utf-8 characters in the name
add this file to the git repo
look at the filename in the Git tree pane of qgit → utf-8 characters are escaped like in the example above.

Currently, any and all command line options are passed verbatim to git log. It would be nice to have a command-line option that, instead, tells QGit to open a specific file, as if "Show file (Alt+A)" had been triggered on the file from the GUI. In particular, this would show the history and the blame view for that file.

Having such an option would allow using QGit instead of git gui blame (ancient Tk UI) or plain git blame (no UI), e.g., as the blame viewer in Git Cola. And the blame viewer is actually already written, all that's missing is a way to trigger it from the command line, instead of having to look up the file in the GUI.

I'm using qgit to look at my commits, compare different branches from different remotes to decide which commit I should merge to my master.
I frequently change from one working directory to another (a different git repos).
I'd like my log to be immediately visible, but it is waiting for "Loading working directory changed files...", which is usually not my interest when I'm in qgit (I use git st and vim :Gdiff to do this).
It would be nice if the working directory changes could be computed in background and be accessible only when ready.
Of course with a progress loop to emphasis that something is in progress.

PS by too long I mean many seconds.

The split "Log" and "Diff" commit view in the "Split view" mode can be cumbersome on small screens. Neither the log nor the diff can be shown in comfortable viewports.

Same applies in the "Patch" tab (to a lesser extent since that tab takes the whole window space).

TODO: propose an optional alternative commit view with combined log and diff. Investigate on a focus group (easier said...) if it is preferable and, if yes, make it default.

Im trialing qgit as im looking for something simple. QGit looks great, except there is no way by default to push or pull changes?
Am I missing something?

Submitted by Daniel Levin on 2016-01-06.

Since Git 2.5 release Git supports multiple working directories. QGit should be able to open such working copy as usual one.

This change does not require much effort as far as I see:

• Normally .git is a bare repository, in separate working tree it is a file with path to bare repository
• HEAD and ORIG_HEAD can be located not in .git/ but in original barerepository/worktrees/barerepository/worktrees/tree_name

In addition QGit should also support opening bare repository to show history without HEAD.
This can be addressed in separate issue I believe.

In repositories with many branches and/or many remotes the display of a branch names in the context menu becomes very chaotic:

Sorting the branches into hierarchic submenus (splitting by the "/") would largely improve the user experience:

A commit can be viewed in a separate "Patch" tab using the "View patch" (Ctrl+P) action in main "View" menu or context menus. Triggering the action successively on different commits opens them in the same tab (it is still possible to open each commit in its own tab, but let's set this aside for now).

Then in the "Patch" tab, it is possible to navigate to previous or next patches in viewing history using the "Back" and "Forward" commands (Alt+Left and Alt+Right shortcuts).

TODO: add ability to also navigate in commit history using (to-be-added) "Previous" and "Next" actions (shortcuts "Up" and "Down"). This will be uniform with behaviour in the commits "Rev List" view.
TODO: add ability to also navigate in stack of marked commits (resulted from "Filter" operation) using "Previous Marked" and "Next Marked" actions (shortcuts "Shift+Up" and Shift+Down").

Submitted by Andreas Sturmlechner on 2018-04-17.

Qt internal header cleanup makes many packages fail due to missing implicit headers. qgit was only missing one, patch attached.

qgit-2.7-qt-5.11.zip

Submitted by Urs Joss on 2016-05-20.

In version 2.6 (on arch linux (qgit-2.6-1)), I cannot use shortcuts to navigate the diff pane

space, u, d, delete, backspace
More shortcuts that don’t seem to know (but I haven’t been using frequently or at all in <2.6):

Home/End to go to first/last revision
CTRL-+/- for adjusting the font size
While scrolling by mouse works, qgit is still usable. However, fast convenient navigation with keyboard only is quite impaired.

Thanks for taking care of that.

What works:

n/k, i to navigate in the revision list
t to toggle the tree view
s to split the secondary panes
h to toggle the view of the split header

Hello, I started QGit from terminal and I setted a simple "my custom action" as follow:

git pull

But on custom action click I receive this error in console:

ASSERT in customAction_activated, action &my custom action not found

It happens with every action.
I'm using official x86_64 package on archlinux.

https://www.archlinux.org/packages/community/x86_64/qgit/

Submitted by Josh Nijenhuis on 2016-09-07.

really annoying to have to move over to the right most part of screen to close a tab...

also to be in line with every other tabbed program out there

Whenever I refresh the current view, the application focuses the Diff tab instead of the Log tab, which is the one that I had focused before the refresh.

It doesn't matter whether I refresh the view using the File -> Refresh option or if I hit the F5 button. The result is the same.

If the behaviour described here is intentional, I think that it's inconsistent. Because when I choose a commit, the application focuses the Log tab instead of the Diff one, which is the opposite behaviour.

Anyway, if it were intentional, I also believe that Log should be the default tab. Because it show us important information from the current status of the repository (when positioned in the working directory) and the description of the commit (when positioned on a commit). What do you opine?

Thank you ;) .

Submitted by Josef Kufner on 2015-05-28.

Hello,
with 1920px wide screen I would prefer all panes side by side – see attached screenshot.

Simply changing orientation of the QSplitter and moving tabs to upper side is enough. However, there should be some configuration option to switch layout between traditional and wide-screen friendly version.

Have a nice day!

Steps to reproduce:
1- I opened qt-creator repo. (> 55K commits):
2- After it loaded completely memory usage is: 3,009,720 KB
3- Select a commit.
4- Memory usage changes to: 2,165,040 KB
5- Again, select Working directory changes
6- After ~5s it start to do something and memory usage changed to: 3,005,344

So it seems it re-computes working directory changes everytime we select Working directory changes.

Submitted by David Edmundson on 2018-02-15.
This surprisingly un-invasive patch adds high DPI support to qgit.

0001-Add-high-DPI-support.zip

Currently, the head is marked by the lighter green color of the current branch. Unfortunately, this doesn’t work for detached heads.

Directive: mark HEAD explicitely (with a “branch” label).

Bonus: perhaps mark the other symbols too: ORIG_HEAD, FETCH_HEAD, etc.

When using more than one custom parameter (ie, echo --%lineedit:family=my family% --%lineedit:name=my name%) the final command is broken, looking at the code (https://github.com/tibirna/qgit/blob/master/src/inputdialog.cpp#L192), the replace logic seems wrong.
It assume the start/end pos are fixed an not moved, but everything is out of sync as soon as you replaced something before the currently replaced variable.
To continue to use your current code logic, you need to ensure to replace variables in the reverse order they appears in the command, from far right to far left, ie the variable having the highest start pos is to replace first and so on.

There are hidden actions "Previous", "Next", "Previous Marked" and "Next Marked" that are not shown anywhere in the main app. menus, although they are quite useful.

TODO: Add a "Navigate" menu and add in it explicit items for "Previous", "Next", "Previous Marked" and "Next Marked". Also, move the "Back" and "Forward" actions from "View" menu to the new "Navigate" menu, where they will make more sense.

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

In the new 2.8 release, src/config.h still defines the version to 2.7 (twice, once as PACKAGE_VERSION, once as VERSION)

While showing working dir, qgit shows git status output in Log. However, in case git is confugured to use non-ASCII locale (Russian in screenshots below)

qgit fails to display this output correctly:

This doesn't happen when displaying actual commits log, UTF-8 is displayed correctly there.

On Fedora 25 with qgit 2.7 clicking on individual commit in the file view (in the list of changes on that file) does not open the commit. The window with Rev list is opened but the revision opened is still the original one that was displayed in the Rev list before and not the desired revision.

Also rightclick on the commit in the file view does not open the contextual menu. This seems to be related to the problem above as both these problems started to appear in the same time. It seems to be some kind of race condition as on 2.6 the commit usually opened but sometimes not. In 2.7 the commit is never opened.

Is possibile to use system icons under linux?
Tipically adwaita under gnome and breeze under KDE Plasma.

Thanks you

Although I try to make my commits as much granular as possible, sometimes I can't avoid to include many files into a single commit. For example, in Java, renaming a single class may affect hundreds of classes.

In this situation, it would be fantastic to have a text field with which I can filter the files shown in the list, by their path, using one or more regular expressions.

Other situation in which it may be useful is when you view the differences between 2 distant commits (using the Diff to: SHA option). Here the amount of files may be overwhelming. But relying on this field, one could spot a file (or group of files) faster.

Thank you for this great application!

When viewing the patches for a given file (after double clicking on the file in the "Git tree") one would expect that double clicking on a commit would show the commit/patch. Instead it brings up the full list of commits. This may have been useful at some point - and may still be - if the commit was selected there. Unfortunately it is not but the list is on whatever was selected previously.

I suggest to not go to the full list at all but just open the commit directly in the "Patch" tab - the same way as when double clicking on the full commit list. The patch could also be selected in the full commit list to be able to access the surrounding patches (assuming the patch is visible in there and not filtered out)

I'm using qgit 2.8 from Debian and found that qgit will crash on some certain git repositories.

Downstream Debian report: https://bugs.debian.org/926327

Compressed git repo: https://drive.google.com/open?id=1yMVLNQ3t6JP4n3Nv_Cnsp7mPrLhT3rQ1

Methods to reproduce:

1. extract the broken git repo from .tar.xz tarball
2. run "qgit" within the working directory
3. select "whole history" in range selection
4. the program will crash.

-> % qgit
ASSERT in Cache::load, corrupted SHA after �yyy�
ERROR: unable to load file names cache
[1]    17309 segmentation fault  qgit

Hi:

I think that it would be useful to be able to configure the width or size of the tab character (U+0009). I'm referring to that parts of the application that show source code, such as the diff bottom pane, the Patch tab, the tab that shows the content of each file, etc.

Thank you.

I found this repository when I was looking for the bug track system for this project. I did it for Google, once links in https://www.openhub.net/p/qgit are either outdated or absent at all. Once there is a new site for the project, It would not be a bad idea update the project there. More contributors could find the project by means of that tool.

Submitted by ralfj ralfj on 2017-07-05.

Steps to reproduce:
Open the file browser side-bar
Double-click some file to view its history
Double-click an item in the commit list in the top half of the window
Expected behavior:
The commit view opens, showing the double-clicked commit.

Actual behavior:
qgit switches focus to the “Rev list”. It selects the “Nothing to commit” at the top of the list, so this is pretty useless.

Messages in annotated tags can be useful. They also have meaningful SHAs.

Submitted by Petr Mrazek on 2017-05-16,

Basically, when the history consists of many small merges, it gets too wide to make sense of.
See attached image for example.

How to reproduce:

• have QGit compiled (with Qt5) from the "compile_with_Qt5"
• open the qgit git repo
• click on a revision
• type 'G' a few times => the treeview seems to change focus as if this triggered a search
• after a few times typing 'G', QGit crashes.

Today’s behavior, that makes the description column not wide enough and the author or date column way too large, is harmful for usability.

Compute the minimum/optimal size of contents and resize automatically. If this optimal sizing is changed by the user manually, record it and restaure it at restart.

Q: save by repository?

When i create actions without giving them mnemonic key (ie &pull), then clicking the menu action trigger an issue telling the action name was not found.
I had to press Alt key while menu is popped to see the mnemonic in the actions text and rename all my custom actions to place the mnemonic so that everything match and works.

Linux, KDE, Breeze

Hi, i've used qgit for years and want to make it better.

Currently qgit calling git as external process and parsing it's output.
It works, but this way is slow and potentially very buggy: we depends from OS process execution mechanics and git version at least.

The most powerful git GUI GitKraken use special library: libgit2.
It is a low-level and lightweight library written in pure C, with minimum dependencies.
Can libgit2 be useful to qgit?
or maybe calling git process was intentional and "by design", and no other way is needed?

However, i will play with libgit2 for my own purposes.
And i can try to integrate to qgit if it will make sense.

P.S. external libraries be used thru e.g. Conan or just bundling it sources as git submodule.

Sorry if this sounds like a question and not an issue, but maybe it could results in an updated documentation or some new feature.

I have a couple of custom diff commands (e.g. using word-diff and special diff-commands for .tex files) defined in ~/.gitconfig. How can I use them in qgit?

[alias]
    wdiff = diff --color-words --word-diff --patience

Submitted by Andrey Rahmatullin on 2016-03-27.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791484

“"”
I have a local pre-commit hook set up to run some stuff right before the actual commit. This works just
fine when committing on the command-line. However, when I commit in QGit, it pops up a message saying
that there was an error committing and showing the output of the pre-commit hook. There was no error,
the exit code of everything is 0 when I run this on the CLI. QGit should thus not say anything about
errors, and it should re-load the commit log to show the new commit.
“"”

Hello,
I ported this Qgit to OS/2 using cmake
Compiling went well, but when i load a git repo to it i see "ERROR: unable to start 'git log'

we have git 2.11.0

i have uncomment USE_QPROCESS in dataloader.h and now is the error about git log gone,
only now i see other error:
See https://i.imgur.com/J0CKL7z.png

Any idea how this get fixed?

Hi!

Thanks a bunch for QGit! Since gitg keeps crashing on me to the point of not starting up at all for some repositories, QGit is a great thing to have, and its unique approach to visualization has turned out helpful a few times already — thanks!

I noticed that README uses special syntax but it's not rendered by GitHub due to lack of a file extension. It looks like reStructuredText to me. Are there reasons to not rename it to README.rst to keep rendering disabled?

Best, Sebastian

There is a big gap between the ref names and the text following them in the 'Rev list' view under MacOS. See screenshot:

It works fine (no gap) when running QGit in debug mode. But in this case, the fonts are very pixelated.

It seems, QGit generates random cryptic filenames to be viewed by External Diff tool.
Instead It should pass over real(existing) filenames for a working dir files.

This way any changed in working dir files can be reviewed and corrected using External Diff right before commit.

Thanks for consideration