gitg issueshttps://gitlab.gnome.org/GNOME/gitg/-/issues2024-03-10T16:44:23Zhttps://gitlab.gnome.org/GNOME/gitg/-/issues/455Nightly version's desktop file name metadata is complex, shows up as "(Nightl...2024-03-10T16:44:23ZJeff FortinNightly version's desktop file name metadata is complex, shows up as "(Nightly) gitgDevel" instead of "Gitg" in the launcherThis is a somewhat non standard name from the desktop file:
![Screenshot_from_2024-03-03_10-11-25](/uploads/af7d3050880f57eab119092c7f718ff2/Screenshot_from_2024-03-03_10-11-25.png)
For comparison, other apps that have nightly flatpak ...This is a somewhat non standard name from the desktop file:
![Screenshot_from_2024-03-03_10-11-25](/uploads/af7d3050880f57eab119092c7f718ff2/Screenshot_from_2024-03-03_10-11-25.png)
For comparison, other apps that have nightly flatpak versions name themselves identically to the stable versions, they simply use the icon to differentiate the two versions:
![Screenshot_from_2024-03-03_10-10-48](/uploads/669dd2ea131a7637697ed30ec9e0bf0a/Screenshot_from_2024-03-03_10-10-48.png) ![Screenshot_from_2024-03-03_10-11-01](/uploads/d89ba6b6a7a4bc5c5a98459e37bab673/Screenshot_from_2024-03-03_10-11-01.png)https://gitlab.gnome.org/GNOME/gitg/-/issues/451On startup and when entering staging view for the first time, Gitg pre-select...2024-03-10T02:47:25ZJeff FortinOn startup and when entering staging view for the first time, Gitg pre-selects all the modified unstaged files in the sidebar, causing slow performanceI was wondering why sometimes Gitg was lagging when entering the staging area view. It turns out that, as you can see in this video, on the first time you enter that view after launching Gitg and opening your repository, it will automati...I was wondering why sometimes Gitg was lagging when entering the staging area view. It turns out that, as you can see in this video, on the first time you enter that view after launching Gitg and opening your repository, it will automatically pre-select all the "Unstaged" modified files in the sidebar:
![Gitg_auto-selecting_unstaged_files_in_the_sidebar__performance_problem_](/uploads/a748945dc92003ede73ba2cfd35c6cb6/Gitg_auto-selecting_unstaged_files_in_the_sidebar__performance_problem_.webm)
…it should absolutely _not_ do that. In fact, it should never auto-select files for you in the sidebar, because this can be extremely costly in terms of performance if one (or many) of your unstaged modified files has hundreds of lines of changes (particularly true with generated things like `.po` / `.pot` translation files).
This performance problem compounds exponentially when you have a repository where there are many `.po` files that have been touched by a script such as `ninja -C .local_build whatever-pot whatever-update-po`, in my case it makes the staging view lag for multiple seconds when entering it, and everytime you make a selection in the sidebar.https://gitlab.gnome.org/GNOME/gitg/-/issues/456Show real application names (from .doap file) in the projects home view2024-03-03T17:51:33ZJeff FortinShow real application names (from .doap file) in the projects home viewGitg is aware of project folders' metadata (as it shows project descriptions, such as "A simple GNOME 3 maps application", from the app's .doap file).
However, it seems like it only uses the raw folder name as the title header for eac...Gitg is aware of project folders' metadata (as it shows project descriptions, such as "A simple GNOME 3 maps application", from the app's .doap file).
However, it seems like it only uses the raw folder name as the title header for each row in the projects view.
It could be nicer to show the human-readable beautified project name from the .doap file (and/or App Metadata), instead.
The project's folder name could be moved and put in bold letters at the end of the existing path name 3rd label line:
![gitg_projects_home_view_app_names_mockup](/uploads/d0220e6f53e0a225fca2f9dce437f343/gitg_projects_home_view_app_names_mockup.png)
…with some italic markup for the branch and bold for the path name, for example:
> ### GNOME Maps
> A simple GNOME 3 maps application
> _"main"_ at /mnt/extend/dev/**gnome-maps**
If no appdata-provided "beautified" project name is available, simply show the folder's name as it already does now, as a fallback.https://gitlab.gnome.org/GNOME/gitg/-/issues/416need smarter display of commit graph2024-03-03T14:29:02ZOswald Buddenhagenneed smarter display of commit graphwhile gitg has definitely the best commit graph rendering of all tools i tried, it still becomes basically useless in repos that use gitflow, because of the huge number of branches and merges. an example of that is the git repo itself, i...while gitg has definitely the best commit graph rendering of all tools i tried, it still becomes basically useless in repos that use gitflow, because of the huge number of branches and merges. an example of that is the git repo itself, in particular gitster's fork on github (which contains all source branches for 'seen').
i'm starting out with the assumption that topological order is used (because #118).
the first thing i'd change is that i'd consistently sort the 2nd parents of merges before the 1st, traversing depth-first, rather than sorting by date. that way the merged branch's contents would be always adjacent to the merge commit.
secondly, i'd elide the branch lines _much_ more aggressively.
* if the enclosing nodes are too far apart to fully fit the line into the view, then it makes no sense to have it, as one won't be able to keep track of it anyway (at least without #414, but even with it it's tiresome).
* it probably makes sense to qualify this with "if the line is not straight", which would mostly exclude long-lived branches.
* as a corollary, if the whole elision doesn't fit into view, then its ends should be cut as short as possible.
* one may argue that all this would make following the lines _even_ harder, but this should be compensated for with #415futurehttps://gitlab.gnome.org/GNOME/gitg/-/issues/454Consider renaming "Branches" to "Local branches" and "All commits" to "Everyt...2024-03-03T07:25:45ZJeff FortinConsider renaming "Branches" to "Local branches" and "All commits" to "Everything", and setting explanatory tooltips on those rowsFor many years, I thought I could only click on individual branches, individual remote branches, and tags. I did not know I could have special summary views by clicking the headings such as "Branches", "Remotes", a remote's name, or "All...For many years, I thought I could only click on individual branches, individual remote branches, and tags. I did not know I could have special summary views by clicking the headings such as "Branches", "Remotes", a remote's name, or "All commits".
I would suggest:
* Renaming "Branches" to "**My branches**" or "Local branches", and setting a GtkTooltip that says,
_"Click to view all your local branches in a graph, relative to each other."_
* Renaming "All commits" to "**Everything**", and setting a GtkTooltip that says,
_"Click to view all branches (local and remote), refs, tags, and stashed commits."_
Without this, it is hard to know that there is still at least _one_ way to see your stashed commits! Otherwise, as it is no longer visible in views other than "All commits" (as per #33), users may not know it is possible at all.https://gitlab.gnome.org/GNOME/gitg/-/issues/452"Collapse inactive lanes" setting (and early vs late slider) does not auto-re...2024-03-03T07:15:33ZJeff Fortin"Collapse inactive lanes" setting (and early vs late slider) does not auto-refresh the view, making it hard to know what it doesMost settings in the `Preferences > History` tab are instant-apply, you can see the resulting changes as you toggle them. However, the "Collapse inactive lanes" and its sub-setting ("Early" vs "Late" slider) do not apply the changes unti...Most settings in the `Preferences > History` tab are instant-apply, you can see the resulting changes as you toggle them. However, the "Collapse inactive lanes" and its sub-setting ("Early" vs "Late" slider) do not apply the changes until you manually refresh the view with `Ctrl+R`, which makes it hard to know what it actually does in practice.
![image](/uploads/24e52c5bf80a572b79ac32e7dae3c1bf/image.png)
Ideally, changing those settings should preview the changes in realtime, or if too slow/expensive, trigger a refresh of the history graph after a 1-2 seconds delay.
Otherwise, if this is not feasible, then these settings should have a warning label (or at least a GtkTooltip) to indicate that the result of those changes are not shown in realtime, only on the next refresh of the timeline (maybe then provide a refresh button there that (re)appears everytime you change the value of those settings… but if possible, it would be better/cleaner to just auto-refresh).https://gitlab.gnome.org/GNOME/gitg/-/issues/453When "Collapse inactive lanes" preference checkbox is unchecked, the "Early" ...2024-03-03T07:08:49ZJeff FortinWhen "Collapse inactive lanes" preference checkbox is unchecked, the "Early" vs "Late" setting slider should be disabled/insensitiveTo make the dependency relationship between those two widgets clearer:
![image](/uploads/24e52c5bf80a572b79ac32e7dae3c1bf/image.png)
…the slider widget should be GTK "insensitive" status when the "Collapse inactive lanes" widget is tur...To make the dependency relationship between those two widgets clearer:
![image](/uploads/24e52c5bf80a572b79ac32e7dae3c1bf/image.png)
…the slider widget should be GTK "insensitive" status when the "Collapse inactive lanes" widget is turned off.https://gitlab.gnome.org/GNOME/gitg/-/issues/110Wrong project selected when right-clicking Projects list2024-03-01T22:43:05ZBugzillaWrong project selected when right-clicking Projects list## Submitted by John `@JohnAJ`
**[Link to original bug (#792881)](https://bugzilla.gnome.org/show_bug.cgi?id=792881)**
## Description
When right-clicking a project in the Projects list, the "selection mode" is activated, but instead...## Submitted by John `@JohnAJ`
**[Link to original bug (#792881)](https://bugzilla.gnome.org/show_bug.cgi?id=792881)**
## Description
When right-clicking a project in the Projects list, the "selection mode" is activated, but instead of selecting the clicked project (or not selecting any project, which would also be acceptable) the *first* project in the list is selected.
This is fairly dangerous, particularly for users with a large number of projects, as it is easy to miss that the first project has been unintentionally selected, and thus, easy to accidentally delete projects. (In fact, that's what happened to me.)
Version: 3.26.xhttps://gitlab.gnome.org/GNOME/gitg/-/issues/447Ability to select and copy a commit's message (summary title and body) to cli...2024-02-25T01:07:37ZJeff FortinAbility to select and copy a commit's message (summary title and body) to clipboard## Usecase
I very often use Gitg's commit details pane (in the History view) to grab some information or inspiration from existing commit messages, or to prepare to rewrite some derivative commit messages when committing something new (...## Usecase
I very often use Gitg's commit details pane (in the History view) to grab some information or inspiration from existing commit messages, or to prepare to rewrite some derivative commit messages when committing something new (or when doing a rebase, with the terminal and text editor).
## The problem
Unfortunately, Gitg makes it very difficult to effectively copy the full commit message, because it is impossible to select the whole commit message at once: you cannot drag-select text across lines in the commit details' message body area. You can only select one line at a time, and the only quick way to select a whole line is to triple-click the line, which selects only that line... so effectively, this is the only workaround I have: triple-click, `Ctrl+C`, `Ctrl+V`, then triple-click the next line and so on, doing the same for every individual line. Very inefficient.
## Expected UX
Gitg should let me select all the lines (including subject line and body) in one go; if that is impossible because of the commit hash widget inbetween, then it should offer a button to "Copy commit message to clipboard" (or "Copy commit metadata to clipboard"?); or at least a way to do this by right-clicking the commit in the History graph treeview.https://gitlab.gnome.org/GNOME/gitg/-/issues/437Offer clickable buttons to Find next/previous result in commit history2024-02-16T08:13:13ZGhost UserOffer clickable buttons to Find next/previous result in commit historyCould you please consider adding a feature for finding the next/previous result in commit history?
![resim](/uploads/e7a1de2233d4ad259db684e7780ae7ae/resim.png)
Related links:
- https://gitlab.gnome.org/GNOME/gitg/-/issues/60
- https:/...Could you please consider adding a feature for finding the next/previous result in commit history?
![resim](/uploads/e7a1de2233d4ad259db684e7780ae7ae/resim.png)
Related links:
- https://gitlab.gnome.org/GNOME/gitg/-/issues/60
- https://gitlab.gnome.org/GNOME/gitg/-/commits/wip/albfan/search-buttonsAdrien Dorsazadrien@adorsaz.chAdrien Dorsazadrien@adorsaz.chhttps://gitlab.gnome.org/GNOME/gitg/-/issues/446Commit details' auto-hyperlinking (of HTTP / HTTPS) is off by one character (...2024-02-12T18:16:00ZJeff FortinCommit details' auto-hyperlinking (of HTTP / HTTPS) is off by one character (or more)With version `45.alpha` as well as the git version built with GNOME Builder, gitg's `parse_links_on_subject` and `parse_smart_text` methods in [libgitg/gitg-diff-view-commit-details.vala](https://gitlab.gnome.org/GNOME/gitg/-/blob/master...With version `45.alpha` as well as the git version built with GNOME Builder, gitg's `parse_links_on_subject` and `parse_smart_text` methods in [libgitg/gitg-diff-view-commit-details.vala](https://gitlab.gnome.org/GNOME/gitg/-/blob/master/libgitg/gitg-diff-view-commit-details.vala) (as implemented by @gaurav1999 in 79a10fbf8 for issue #152) seem to create hyperlinks that are typically off by one character (and sometimes more).
You can see this with the blue underlined portions in the screenshots below; those are all commits from gitg's repository (so you can easily reproduce the problem using gitg's search feature).
`ec8d97d5c4913`:
![image](/uploads/9ea69cad499f880fcdb35094fe2db381/image.png)
`da0e21aa13a` (this one seems to behave in a very special way):
![image](/uploads/e3a637e31280bf245f65cb898d7cddcc/image.png)
`8ef12dc80c`:
![image](/uploads/9f01bc79028a11f71af88839383fb996/image.png)
`79a10fbf8`:
![image](/uploads/dab1aee70329032860f91612a6567c2b/image.png)
`e86a333` (this one seems to behave in a very special way):
![image](/uploads/ac6e660cb480b1e73c64f5a708e84be5/image.png)
---
Overall, the hyperlinks themselves still work correctly (i.e. they open the correct URL) and even then _it used to not have hyperlinks at all,_ so in practice this is a minor non-urgent cosmetic issue that would be "nice to fix".https://gitlab.gnome.org/GNOME/gitg/-/issues/445Automatically recognize / parse and hyperlink email addresses in commit messa...2024-02-12T17:42:25ZJeff FortinAutomatically recognize / parse and hyperlink email addresses in commit message body trailers (for co-authors, reviewers, signed-off-by, etc.)This is a low-priority "nice to have" UX feature request.
As seen in various places out there in the wild (such as [this commit](https://cgit.freedesktop.org/libreoffice/core/commit/?id=5c12939540faf) for example), there is a standardiz...This is a low-priority "nice to have" UX feature request.
As seen in various places out there in the wild (such as [this commit](https://cgit.freedesktop.org/libreoffice/core/commit/?id=5c12939540faf) for example), there is a standardized practice of adding "trailer" metadata to the end of commit messages, which typically looks like this:
```
Change-Id: some_big_commit_hash_or_something_else
Co-authored-by: some person's name <their_email_address@example.com>
Reviewed-by: some person's name <their_email_address@example.com>
Reviewed-by: some other person's name <test@example.com>
Tested-by: some person's name <their_email_address@example.com>
```
Currently, Gitg will show all of those as-is, in plain text.
Ideally, it would be nicer if it hyperlinked the email addresses onto the names instead (with `<a href="mailto:the_email_address" title="the_email_addres">The person's name</a>` so that the email address can be seen on hover with the tooltip).
There already is some code to parse regular hyperlinks (with the `parse_links_on_subject` and `parse_smart_text` methods) in [libgitg/gitg-diff-view-commit-details.vala](https://gitlab.gnome.org/GNOME/gitg/-/blob/master/libgitg/gitg-diff-view-commit-details.vala), so someone who is well-versed in the dark art of regex (definitely not me!), or perhaps less dangerous techniques, could maybe extend this for `*-by: some_name <some_email_address>` to be presented more nicely?https://gitlab.gnome.org/GNOME/gitg/-/issues/281Blame mode removed since 0.3.12024-02-12T03:08:46ZJohannes RaggamBlame mode removed since 0.3.1The blame mode was added in 0.2.4 ( https://gitlab.gnome.org/GNOME/gitg/-/commit/9e560ab9e1e14c1e805ee55613111f78090b312d ) was removed in this commit and apparently never added back:
https://gitlab.gnome.org/GNOME/gitg/-/commit/a74c5661...The blame mode was added in 0.2.4 ( https://gitlab.gnome.org/GNOME/gitg/-/commit/9e560ab9e1e14c1e805ee55613111f78090b312d ) was removed in this commit and apparently never added back:
https://gitlab.gnome.org/GNOME/gitg/-/commit/a74c5661a672712ddb96bd70d51fadea23dda933
Would be great to have this feature back...https://gitlab.gnome.org/GNOME/gitg/-/issues/65Option to always expand commits2024-02-12T03:04:48ZBugzillaOption to always expand commits## Submitted by Lionel Landwerlin `@djdeath`
**[Link to original bug (#776054)](https://bugzilla.gnome.org/show_bug.cgi?id=776054)**
## Description
One thing I quite like from gitk is it's possible to skim through the commits and fr...## Submitted by Lionel Landwerlin `@djdeath`
**[Link to original bug (#776054)](https://bugzilla.gnome.org/show_bug.cgi?id=776054)**
## Description
One thing I quite like from gitk is it's possible to skim through the commits and from one commit to the other, have the view in the roughly the same state.
It would be great if while going through commits I could looking the diff without having to click "Expand all" for every single one.
Version: git masterhttps://gitlab.gnome.org/GNOME/gitg/-/issues/183improve manage staging area keyboard shortcuts2024-02-12T02:47:26Zsoloturnimprove manage staging area keyboard shortcutsi reformatted the code of a whole project, which changed a 100 files or so. when i wanted to browse quickly the changes i could not find keyboard shortcuts to navigate the changes. go to next file, page down in a file, add to the staging...i reformatted the code of a whole project, which changed a 100 files or so. when i wanted to browse quickly the changes i could not find keyboard shortcuts to navigate the changes. go to next file, page down in a file, add to the staging area, remove from staging area.
not so intuitive i found:
* space adds a file to the staging area, pressing again space does not remove it.
* could not page down the diff view without mouse. pgdn goes down the file tree.
* then i tried vi or emacs shortcuts. but, typing a letter opens a search window but does not find anything.GNOME 44https://gitlab.gnome.org/GNOME/gitg/-/issues/409User avatar should be vertically aligned to the top in commit metadata header...2024-02-12T02:45:33ZJeff FortinUser avatar should be vertically aligned to the top in commit metadata header (especially when author differs from the committer)The author's avatar is currently vertically centered, however this causes a problem when the person who committed/merged/pushed a commit is different from the commit's author (whose avatar is being displayed), because then the author's a...The author's avatar is currently vertically centered, however this causes a problem when the person who committed/merged/pushed a commit is different from the commit's author (whose avatar is being displayed), because then the author's avatar is not aligned with their name:
![image](/uploads/62ede2b1a4efb57946bc5d2110f2ffc9/image.png)
It also causes an alignment problem when a commit has author information without committer information:
![image](/uploads/2e1c8ce5b91c75244402cafe0fecdfbd/image.png)https://gitlab.gnome.org/GNOME/gitg/-/issues/400Ability to checkout remote branches in a detached state (without creating a c...2024-02-12T02:44:45ZJeff FortinAbility to checkout remote branches in a detached state (without creating a corresponding local branch)In issue #293, @armandas implemented the ability to checkout remote branches. However, looking at the current GUI for it, it seems like it always creates a local branch in the process:
![image](/uploads/879a34cf5a0a0d89aa15f887bf1e77cb/...In issue #293, @armandas implemented the ability to checkout remote branches. However, looking at the current GUI for it, it seems like it always creates a local branch in the process:
![image](/uploads/879a34cf5a0a0d89aa15f887bf1e77cb/image.png)
If you remove the contents of the text field, the "Checkout" button becomes insensitive.
I would like to be able to do checkouts without creating local branches, like I can do on the command line. This is very useful as a QA person when I simply want to temporarily test someone else's branch by switching to it and launching the app from GNOME Builder, without polluting my side of things.
Ideally the UI (and backend) should allow this, and the either:
* the "Local branch name:" label could have a " (optional):" suffix, or;
* there could be a hint/tip label above it all, that explains you can clear it to checkout in a detached state, or;
* the UI could be flipped upside down a bit and have the remote branch widgets at the top, then a separation label that says, "If you wish a local branch to be created, indicate its name below:", then the GtkEntry ?https://gitlab.gnome.org/GNOME/gitg/-/issues/15Explicit stash changes command2024-02-12T02:31:37ZBugzillaExplicit stash changes command## Submitted by Adam Dingle
**[Link to original bug (#648323)](https://bugzilla.gnome.org/show_bug.cgi?id=648323)**
## Description
It's nice that gitg offers to stash my changes for me if I try to merge when I have uncommitted chang...## Submitted by Adam Dingle
**[Link to original bug (#648323)](https://bugzilla.gnome.org/show_bug.cgi?id=648323)**
## Description
It's nice that gitg offers to stash my changes for me if I try to merge when I have uncommitted changes in my working directory. It would also be nice if there were an explicit command to stash changes. In other words, I'd like to be able to right click on my unstaged (or staged) changes in the main gitg view and choose Stash Changes to stash them directly.
Details: of course, stashing works on all uncommitted changes both staged and unstaged. So if I have both staged and unstaged changes, I could run this command on either one and the effect would be the same: both staged and unstaged changes would be stashed. We could display a confirmation message prior to stashing which would make this clear.
Version: git masterfuturehttps://gitlab.gnome.org/GNOME/gitg/-/issues/434Deleting a branch from the commits history list view does not remove it from ...2024-02-12T02:03:26ZJeff FortinDeleting a branch from the commits history list view does not remove it from the sidebarThis is a minor GUI issue, but, with version 44 (aka 45.alpha):
1. In the history's view of commits, right-click a local branch's name bubble
2. Select "Delete…"
Result: the branch is effectively deleted in the backend and from the his...This is a minor GUI issue, but, with version 44 (aka 45.alpha):
1. In the history's view of commits, right-click a local branch's name bubble
2. Select "Delete…"
Result: the branch is effectively deleted in the backend and from the history's commits list view, however it is not removed from the sidebar on the left.Claudio Silva JuniorClaudio Silva Juniorhttps://gitlab.gnome.org/GNOME/gitg/-/issues/392Split diff (side-by-side code comparison) view mode state should be global an...2024-02-12T01:45:28ZJeff FortinSplit diff (side-by-side code comparison) view mode state should be global and automatically rememberedThanks for the "Split" button providing an alternative to the "Unif" view, in the latest version of Gitg! It's great.
However it doesn't remember my preference across sessions, or even across commits. And it requires me to click it for ...Thanks for the "Split" button providing an alternative to the "Unif" view, in the latest version of Gitg! It's great.
However it doesn't remember my preference across sessions, or even across commits. And it requires me to click it for every single file.
When switching to split or unif view, it should remember that in a gsetting and apply that to any other commit I select, even after restarting the app.
Also, I don't see why users would want/need to have this choice be per-file per-diff, it should be a global toggle instead. The current approach is cluttering up the UI pretty significantly, not to mention it creates a lot of unnecessary work (if I'm reviewing a bunch of files, why would I want a different diff style for each? It's going to take me dozens/hundreds of useless clicks, so that's creating [sh!twork](https://zachholman.com/posts/shit-work/) for users):
![image](/uploads/48186142541f1e508ef80050db70ea43/image.png)