Recently, IntelliJ introduced autocompletion in commit messages for code references. It would be nice to have this in git-gui, too.

I wanted to create an initial commit to a new repo that was backdated, and had many of the classic environment variables (committer & author name, date, and perhaps --allow-empty, --orphan, etc) adjusted. This feels like this need a moderately common tasks where hindsight [foresight] would have been a great thing.

I thought it worth logging the Idea that the GUI should have, within the Commit menu dropdown, an "All options Commit" dialog. Food for thought anyway (I'll just have to use the command line in the mean time)

Right now, all the gui.commitmsgwidth config variable does is set the size of the commit message window, so users get a visual hint on when to manually wrap their text. A much better quality-of-life feature would be to wrap the text for the user.

Also, allow disabling the line wrap for people who don't want it.

Wrapping the display text of the commit message text box is easy to do. The -wrap option of the text widget can wrap the displayed text. I haven't looked too much into the option, but AFAIK it only soft-wraps the text.

So, we need to hard-wrap the text before passing it to the commit machinery. The main challenge is to make sure our wrapping algorithm works exactly like the text widget's wrap, otherwise the users would see one thing and the commit would contain something else.

It would also probably be a good idea to allow not wrapping a line. Maybe we can do something like mbox subject lines where if the first character of the line is a space, it is considered a part of the previous line.

An alternate implementation to using -wrap would be to run the text wrapping logic every time the user types something (probably by using tags). This would remove the need to match Tcl's word wrap implementation, but might have a performance hit.

Menus can be popped out by using the "line" at the top of every menu item under the top menu bar. It would be nice to remember where they were propped up when git-gui is closed, and their state restored when it is re-started.

Also consider adding an option to disable this behaviour in case some people don't like it.

Right now, if caps lock is pressed, the behavior is the same as when shift is pressed. So, if we add a binding for Ctrl-a, we also need to add one for Ctrl-A. Otherwise, Ctrl-a won't work when Caps Lock is pressed, since that is recorded as Ctrl-A.

This means that we can't use shift as a modifier. So, it might be a good idea to remove that limitation, and do the same thing regardless of if Caps Lock is pressed or not.

I'm not sure how something like this can be done. If Tk's bind function provides a way to do this, it would be great, but we might have to end up rolling our own hack on top of bind.

Hi
This refers to the latest Tcl/Tk git-gui.sh code git version 2.17.1, from https://github.com/git/git.
It's not a new thing. It has been present in git-gui since the beginning, I believe.

Problem:
When expanding the top level window of the stock git-gui interface, the 'Commit Message' text widget remains fixed in size. Long message lines may be partially hidden, since the same text widget has its -wrap option set to none, and the rest of the now expanded area to the right of the text widget remains empty, as far as I can see, unless there is some other functionality that uses that empty space, which I have not encountered over the years.

Proposed solution

1. Allow the 'Commit Message' text widget and its containers to expand to the edges of the enclosing frame, when the top window changes size (patch 1).
2. Change the text widget's -wrap option to word and
3. Adjust spacing between (non wrapped) lines to improve text appearance (patch 2).

Attached are two trivial patches and three images of the resulting appearance.

Thanks.

git-gui.zip

See https://bugs.debian.org/951081 for description of a bug I've just reported in debian.

(You might be also aware of https://bugs.debian.org/950597, 'git-gui "Show History Context" raises "Application Error"' which also might be related to recent changes in git gui).

I am running git-gui version 0.21.GITGUI with git version 2.26.2.windows.1 on Windows 10.
When I stage a new file the following error is shown in a popup window:

Index Error
Updating the Git index failed. A rescan will be automatically started to resynchronize git-gui.

warning: CRLF will be replaced by LF in path/to/file.
The file will have its original line endings in your working directory

I can choose to "Unlock Index" or "Continue".
I choose "Continue". The former window closes and a new error window pops up:

Application Error:
Error: wrong # args: should be "ui_ready"

wrong # args: should be "ui_ready"
wrong # args: should be "ui_ready"
    while executing
"ui_ready ui_ready"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 $after"
    (procedure "select_first_diff" line 8)
    invoked from within
"select_first_diff $after "
    (procedure "rescan_done" line 15)
    invoked from within
"rescan_done $fd buf_rlo $after"
    (procedure "read_ls_others" line 14)
    invoked from within
"read_ls_others file3d689f0 {reshow_diff; ui_ready ui_ready}"

When I choose "OK" then the windows closes and the file is staged.

Sorry, not too familiar with git-gui or even working in Ubuntu desktop. Most things in the desktop seem to work as expected but I can't copy the text out of the pre-commit hook failed window that shows up when i use git-gui to commit.

Is this a git-gui bug or possibly an ubuntu issue (although I have not come across anything else in Ubuntu that was showing this issue)?

Remote \ Add \

• D:..
• Initialize ..

Results into :

fatal: GIT_WORK_TREE (or --work-tree=) not allowed without specifying GIT_DIR (or --git-dir=)

git-for-windows/git#3149

As you know, I'm a Chinese and everytime I have to first translate the items and then choose. I wonder if you can provide a place for localization, where we can translate the texts and submit. (Otherwise it takes a lot of time for me to translate the texts each time.)
Then we will have a localized program!

I was the person who suggested focus_widget, but in hindsight, it is probably not a very good name. A reader might think it can be used to focus any widget. So, it is a good idea to clarify that it is only used for the "staged" and "unstaged" widgets by either renaming it to something clearer, or adding a comment to clarify. I personally would prefer a rename.

Currently, I have to manually alter the theme via injecting ttk::style theme use clam before color::sync_with_theme call ( a gross hack) to work around my problem with tk theming. It works though.

It would be great if I could set a theme to use via settings - git config --global gui.ttk_theme clam. I would unlock other interesting possibilities - like setting theme per repo (git config gui.ttk_theme clam) - although I'm not sure how useful that is.

Hi! This is the first issue I've opened, so please let me know if you'd like any more information.

I'm running into an issue where git-gui will hang indefinitely after pressing Commit while executing a pre-commit hook. I've tracked this to a call to cat > ... in my hook. It seems to me that git-gui is not handling stdin to the child process correctly (this same hook doesn't fail on the command line).

$ git init
$ cat > .git/hooks/pre-commit
#!/bin/bash
cat > x
$ chmod +x .git/hooks/pre-commit

$ touch y
$ git add y
$ rm -f x
$ git commit -m "test"  # returns immediately
$ test -e x && echo created || echo failed
created

$ touch z
$ git add z
$ rm -f x
$ git gui  # Press "Commit" => hangs forever "Calling pre-commit hook..."

I don't see any way to close the stdin to the hook process, so it's impossible to commit using the GUI as-is. I've "solved" this by just adding calls to timeout when I cat, but that doesn't seem like a good long-term solution.

For the record, I'm aware that git won't send me data on stdin for the pre-commit hook, but certain hooks do send data this way (source):

Hooks can get their arguments via the environment, command-line arguments, and stdin. See the documentation for each hook below for details.

Here are the versions of the commands I'm using:

$ git --version
git version 2.31.1
$ git gui --version
git-gui version 0.21.0.99.gdf4f9e

I tried looking through the source, but I only got as far as _open_stdout_stderr since I don't know Tcl 😄

Thanks!

It's quite common for people (self included) to checkout some commit (detached head) or branch (named head) and do some investigation resulting in changes that later they want to be a new branch.

Unfortunately there is a bit of a conceptual merry-go-round (with web questions to match) about which commands to use to update the current head to the users chosen new name, and retain the current changes to the working tree. (Clue it's not the branch command).

It's not clear in the GUI which of the branch commands (branch>>create, or branch>>checkout) should be used to achieve this oft required action.

Can we improve the GUI menu scheme and dialog boxes to make the correct action clearer (esp if the user is on the wrong track)?

I haven't investigated the code yet to see which is the right gui option, but the menus didn't help.

I used to have Ubuntu MATE 18.04 with the Git PPA at https://launchpad.net/~git-core/+archive/ubuntu/ppa . I recently upgraded the system to 20.04.1, and with that PPA I now have git gui version 0.21.0.78.g38c2a.

I do not know exactly what triggered the change, but git gui now displays the file list on the left and the main patch window on the right with a rather dark gray background. The text is black and is no longer comfortable to read. The rest of the system displays a white background as usual.

Apparently, you cannot configure the colours inside git gui. So I searched around and found 2 links, because apparently other people wanted colour changes too:

Link 1) https://bbs.archlinux.org/viewtopic.php?id=193668

The command does not work and I am not familiar with X resource files.

Link 2) https://www.mail-archive.com/[email protected]/msg00194.html

That does not provide enough information, but there is a hint that, being a Tcl/Tk application, you may be able to do such things in some standard way. But I could not find a standard Tcl/Tk way to pass command-line arguments or specify some configuration file to change the theme or any other visual aspect.

Could you at least provide some practical instructions to change the background colour?

Thanks in advance,
rdiez

The "install" target fails if the installation path does not support hard links (I noticed this when installing `git' into a bind-mounted directory).

When installing git' (which comes with git-gui), the install process allows to control the use of hard links via the variable NO_INSTALL_HARDLINKS'. This variable is ignored by the git-gui Makefile, though.

Please see the git bug report for more details and for a patch by Junio C Hamano for fixing the problem.

Thanks.

Denton suggested on the list that I put my TODO list over here so other people can see it and maybe even fix them. So I'm writing some descriptions for them and adding them here.

If a file's state is "added" (IOW, it has the flag 'A'), it is not displayed as a diff. Instead, the content is shown directly. While that makes it easier to read the file (easier than reading a diff anyway), it makes it impossible to selectively stage lines using our current machinery.

So instead, show the added file as a diff and allow selective staging of lines. It would potentially hurt readability a bit since all the lines will be green and prefixed with a '+'. But its not like we do any syntax highlighting, it is probably not a huge difference. Plus, git-diff also shows added files as diffs, so most people shouldn't have a hard time adjusting.

I haven't looked too much into the problem, but my guess is that there are two major things that need to be done: display the "added file" as a diff, and then modify/remove the check in the function apply_or_revert_range_or_line that exits early if the file has a status flag other then 'M'. This check is on the line 690 in lib/diff.tcl as of writing this.

The text cursor when typing in a commit message is not visible while in dark theme.
In light theme the cursor blinks and shows normally. I suspect that the cursor is blinking white.

macOS Catalina 10.15.6
git-gui version 0.21.0.72.g46972
git version 2.28.0

Tcl/Tk version 8.6.10

Hi,

@dahlbyk advised that this might likely be a bug in git-gui. I initially posted this in the posh-git repo, dahlbyk/posh-git#738. This also got linked as potentially related microsoft/terminal#4809.

Original bug report below.

Thank you!

System Details

• posh-git version/path: 1.0.0 beta3 ~\Documents\PowerShell\Modules\posh-git\1.0.0
• PowerShell version: 6.2.4
• git version 2.25.0.windows.1
• OS: Microsoft Windows NT 10.0.18362.0

Issue Description

posh-git seems to work fine overall. However when typing git gui, the git gui window opens, but on the powershell prompt, the encoding of the characters is outputted and the cursor stays on that line. Only after pressing "Enter", the prompt becomes "normal" again.

~\MyProj [mybranch +2 ~2 -0 !]> git gui    <-- nicely colourised
~\MyProj �[93m[�[0m�[96mmybranch�[0m�[31m�[49m +2�[0m�[31m�[49m ~2�[0m�[31m�[49m -0�[0m�[31m !�[0m�[93m]�[0m>    <-- no colours, "weird" output. Have to press "enter" to get prompt to normal again.
~\MyProj [mybranch +2 ~2 -0 !]>    <-- nicely colourised

I can no longer enter text into the commit message box after a hook fails. The rest of the UI (staging / unstaging, hitting the commit button, etc..) seems to work. This is on macOS. If I close and re-open git gui, it works again.

I can reproduce this with commit-msg and pre-commit hooks, have not tried others.

Right now, no keyboard shortcuts or options (the ones that can be opened from the "Options" menu) are not documented. In case of options, most are pretty self-explanatory, but some do warrant a more detailed explanation.

For documenting options, IMHO the best solution would be to use a tooltip. When the user hovers over the option, the tooltip would have a "hint" for it. This tooltip can be created via Tk's Tooltip package.

git-gui also has a homebrew tooltip implementation. Well, two tooltip implementations. The first resides in lib/choose_rev.tcl, and the second in lib/blame.tcl. Most of the implementations are the same, but have some subtle differences. If this implementation is to be used, I recommend writing a generic tooltip implementation from the two existing ones, and then refactor those two to use the common, generic one. This is a significant refactor though, and it might prove to be difficult to write a generic interface that works with both the two implementations. I haven't really looked too much into it so can't really say.

For documenting keyboard shortcuts, I'm not sure what the best place would be. Maybe the man page? I'm not really sure.

All the documentation links point to GIT manuals. I can't find how to add tools through the GUI.

I'm trying to all Open Office Text as a tool to my Git Gui 0.21.GITGUI. I'm writing a book in *.doc, and want to use code line management on it.

Note: this is my first post on this github.com. Apologies if this is covered somewhere that I couldn't find. I searched throughout the site as much as I could.

Thanks!

Text copied in git gui (Right click > Copy) can only be pasted while git gui is running.
Once it's closed, the copied text is removed from the clipboard (i.e. pasting doesn't work).

Tested on Ubuntu 16.04 and 18.04.

Note: gitk suffers from the same issue.

Steps to reproduce:

1. Open gitk
2. Check out a remote branch with a prefix that doesn't have a local branch created yet, e.g. remotes/origin/features/dx-matters
3. Observe that a local branch was created with a name dx-matters
4. Go back to Git GUI, commit any changes, and Push the branch
5. The cluttered "Push Branches" window pre-selects the dx-matters source branch and selects Destination Repository of origin by default

Actual result:

• The user will be notified by their team members that they haven't pushed any changes, and they'll both have to waste time figuring out where are the commits and why doesn't the pull request track them ;)
• Both the remotes/origin/features/dx-matters and remotes/origin/dx-matters will exist on the server, despite the user following quite logical steps (by copying an existing remote branch) and preferring to use GUI to avoid such typos (which in most cases includes newbies who don't exactly know the nuances of how do the branch prefixes work and what's the difference between remotes|origin|features if they're all orange in gitk)

Expected result:

• The user could be at least notified (with some red text) that no remote tracking branch exists for this branch and it'll be created; at least if there is at least one prefixed branch with a same name & without a conflicting prefix (or am I wrong in assuming that almost nobody prefers to deliberately create such conflicting names?)
  • In general, visualizing any expected movement of a remote branch could be very beneficial to make Git more intuitive to use, e.g. by saying that "2 new commits will be pushed" (after all, it isn't possible to make a conflict if you don't force push; and of course, it'd be preferable to have even an option to have the push rejected if the remote branch position didn't match the local one; especially if it has been force pushed in the meantime)
• In the best case, the gitk could be fixed directly (but they don't provide any public issue tracker, so I have no idea what's their stance about this use-case)
• Just like Source Branches, the Destination Repository could also list the "Destination Branches" as a way of selecting an existing branch, which could result in the branch being seemingly renamed before the push
  • The "Arbitrary Location", or a similar text field of a branch name, could support auto-filling a selected branch name; or even an explicit (namespace) prefix without having to manually type the same branch name again (which would introduce tons of typos)
• As another feature request, if the user has to make a temporary tracking branch for the sole purpose of making a push, I could imagine a new checkbox to "Delete the local branch after a successful push" being very useful, considering that the remote branch stays there anyway
  • Of course, deleting the reference has a risk of the remote branch being removed by someone else's force push, which is a good reason not to enable this by default (and risk getting stuff garbage collected in the future); though personally I'd recommend providing us with a new option to fetch without automatically accepting any force push (until explicitly confirmed)

And in general, please, let's all focus on improving the Developer Experience of the stupid content tracker that we all love. There's still so much unnecessary learning curve for new users, yet the UIs have still barely scratched the surface of use-cases beyond simple 'commit & push' :)

Right now, if you want to stage all files, you need to go into "Commit" menu or use the Ctrl-I shortcut. And there is no way to unstage all files.

Going into the menu is cumbersome, and not everyone would want to use a keyboard shortcut, so add some easy to reach buttons to do this. Probably put them right after the red "Unstaged Changes" bar and the green "Staged Changes" bar. Or, put them inside the bars right beside the text.

git-gui version 0.21.0.53.g0d211

When running in dark mode on macOS the UI looks pretty broken and e.g. the cursor is not even visible in the commit message text box.

gitk provides an option to enable/disable "Use themed widgets" which allows you to go back to the normal UI despite using dark mode in the rest of the OS. Something like that should be available for git-gui, too.

Even increasing font sizes isn't enough, as some fonts aren't included in that.

There should be a way to increase the scale of the entire application. It doesn't seem to respect GDK_SCALE, QT_AUTO_SCREEN_SCALE_FACTOR, et cetera.

You can say that this is not a serious issue and one just should avoid misclicks, however, with traditional git commit + editor workflow it's much harder to lose typed text irreversibly.

When you push a branch with Cntl + p + Enter the close button is disabled during the push.

But once the push completes the close button has no focus, so you can't just press enter to close the window, meaning you must use the mouse.

Thanks.

It would be a great quality-of-life improvement, and would allow a degree of customization.

Many IDEs and diff tools not only colorize - and + lines, but also highlight parts of respective which were actually changed, so that common parts can be more visible in complex diffs. For example, see
https://gist.github.com/annulen/884b116d229f04b4e7db8fa6d018e865, which contains screenshot and textual diff which could be used as a testcase. It would be great if such highlighting was available in git-gui.

I think this feature could be implemented in one of following ways:

• Parse output of git diff --word-diff=porcelain. However it also needs a different regex to find "word" boundaries to provide more useful output (like tools on screenshots)
• Parse output of external highlighter which uses ASCII escape codes. There is such highlighter included with git itself - diff-highlight, however it's very basic and cannot handle cases when number of added and removed lines is different (like in my example). Much more robust tool is diffr. In theory it should be to port more advanced highlighting algorithm to perl and replace diff-highlight in mainline git.

cc @ashkulz

And also when is the 1.0 version and what will be in it.

I find that the "latest" release version was in 2016 and then nothing, so I have this question.

In modern git versions when file was both renamed/moved and changed, git diff shows actual diff in content, while git gui still displays old version of file as removed and new version as added.

If there is a file with merge conflicts, git-gui shows options to resolve the conflicts as "ours" or "theirs". But, this resolution applies to the whole file, not individual hunks.

Allowing resolving conflicts per-hunk would be a nice quality-of-life enhancement.

After the release of macOS Big Sur i had to update git and git gui to the last release.
To be more precise git (2.29.2) and git gui (0.21.0.78.g38c2a)

Unfortunely this broke git gui with the dark mode of macos.

For what i understand now git gui retrieve the color for the interface directly from the OS theme but the result is this.

From this issue i have executed following command

git config --global gui.usettk 0

and it does help a bit with the background color of the input box

Do you have some suggestion to how i can change the colors of the buttons?

It would be nice to allow to use the default theme (the white one) until this is fixed

Hello,
I'm using git-gui on Windows (right-click context menu -> Git GUI Here).
After moving my git setup to a new Windows system, and configuring all git options and ensuring git (bash) works fine, I started to use git-gui but to my surprise it does not function properly in remote operations. I checked the options menu and saw that it's missing user name etc. so somehow it is not getting the whole git config parameters (the global parameters definitely) or it got them initially (in first experiments) and did not update afterwards. However when starting git-gui from bash everything is okay.

My questions

1. are git-gui options saved somewhere and where ?
2. does git-gui need specific environment variables set before run (my windows system is corporate with preset environment variables that I guess conflict with git setup where I have set my environment variables in bash's profile) or alternatively can I use a command line option to set where is the global git config file ? (something like GIT_GUI_HOME= ... for example)
3. where is a documentation with all git-gui options (as seen in options menu) and command line options ?

Thank you !

In a project with nested folders or packages the path to a file can show up rather long in the bottom right window .

If this windows cannot take a lot of space due to screen restrictions then the long paths wrap as shown in the following screenshot:

It would be convenient to have the possibility to switch on/off package flattening as it is supported by IDEs such as IntelliJ - shown in the screenshot:

In

git-gui version 0.21.0.93.g7b0cfe1
git version 2.24.3 (Apple Git-128)

Tcl/Tk version 8.6.11

the use of the commit message template is implemented.

Expected behavior. Comment lines (starting with # symbol) are ignored.

Observed behavior. The comment lines in the commit message are included in the commit message.

This would help close the gap in git-gui functionality. The code to display side-by-side diff, and to perform chunk-by-chunk merge can be borrowed from tkdiff.

As of fa38ab6, git-gui requires Tcl/Tk 8.6, however, stock MacOS High Sierra is stuck on Tcl/Tk 8.5.9. This makes git-gui completely unusable on Mac out of the box since the version check makes anything lower than 8.6 a fatal error.

No other part of git-gui requires such an advanced version of Tcl/Tk, so it is unfortunate that git-gui, as a whole, should be held hostage to the relatively minor new feature added by fa38ab6.

Therefore, would it be possible for the new feature to be re-worked so that it falls back to some other method of synchronization if 8.6 is not available, or to avoid performing actions asynchronously for versions less than 8.6? (Or, as a last resort, just disable the new feature when the version is less than 8.6 rather than making git-gui, as a whole, fail outright?)

It would be very convenient if this dialog would be closable with just Escape key.

Additionally and independently, it would be nice for the dialog before that to be closable with Escape, and maybe that Enter would act as "OK".

Right now, tools can be added and deleted via the "Tools" menu, but they can't be edited. To edit a tool, you either need to change it in the .git/config file (or the global config file). There is no way to edit a tool from the GUI.

As per git-commit help.

git-gui doesn't appear to use the template, unlike editors like vim, nano et al.

I noticed that the colors for merge commits diff are not the same as for a regular commit diff.
I customized the colors (green, red) for the regular commit.

Merge commit diff example

Regular commit diff example

I personally don't like the colors of the merge commit diff (red, blue). As far as I know they are not configurable. I would use the same colors as for the regular commit diff. What is your opinion?

The discussion over at [0] suggested that we should probably stop showing the annoying the dialog on startup, and instead start doing auto-gc. Since git-gui mostly uses plumbing commands, auto-gc is not triggered. But it is a pretty good idea to use it.

I have an almost complete implementation over at [1]. I'll try to finish up a few loose ends and send it soon.

[0] https://public-inbox.org/git/[email protected]/
[1] https://github.com/prati0100/git-gui/tree/py/auto-gc

It seems like git-gui is using xdg-open or something like that when clicking on "link" with current file name. It would be great if it was possible to use custom editor with given arguments instead. Bonus points if git-gui could allow passing line number corresponding to currently reviewed diff chunk.

In a recent discussion on the Git mailing list, a user of jupyter notebooks noted the need to test partial commits during a 'merge' of the notebook's changes.

This requires that the worktree reflects the state of staging area with no uncommitted files (I'm assuming a suitable .gitignore file here..). This would need a type git stash of the remaining work (those in the unstaged changes pane), retaining the staged files so as to test the updated notebook for functionality. essentially we have a temporary commit of the staged changes, and a stash of the unstaged changes. (I don't use stash much myself so this is conceptual..)

Is that a reasonable request, and what concerns should be included in any design.

unstage just does not work