diff.tcl: Fixed alignment of tabs in git-gui diff by using spaces. #2179

ChrisIdema · 2026-01-23T13:59:15Z

cc: Johannes Sixt j6t@kdbg.org

gitgitgadget-git · 2026-01-23T13:59:59Z

Welcome to GitGitGadget

Hi @ChrisIdema, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests.

Please make sure that either:

Your Pull Request has a good description, if it consists of multiple commits, as it will be used as cover letter.
Your Pull Request description is empty, if it consists of a single commit, as the commit message should be descriptive enough by itself.

You can CC potential reviewers by adding a footer to the PR description with the following syntax:

CC: Revi Ewer <revi.ewer@example.com>, Ill Takalook <ill.takalook@example.net>

NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description,
because it will result in a malformed CC list on the mailing list. See
example.

Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:

the lines should not exceed 76 columns,
the first line should be like a header and typically start with a prefix like "tests:" or "revisions:" to state which subsystem the change is about, and
the commit messages' body should be describing the "why?" of the change.
Finally, the commit messages should end in a Signed-off-by: line matching the commits' author.

It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code.

Contributing the patches

Before you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form /allow. A good way to find other contributors is to locate recent pull requests where someone has been /allowed:

Search: is:pr is:open "/allow"

Both the person who commented /allow and the PR author are able to /allow you.

An alternative is the channel #git-devel on the Libera Chat IRC network:

<newcontributor> I've just created my first PR, could someone please /allow me? https://github.com/gitgitgadget/git/pull/12345
<veteran> newcontributor: it is done
<newcontributor> thanks!

Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment /submit.

If you want to see what email(s) would be sent for a /submit request, add a PR comment /preview to have the email(s) sent to you. You must have a public GitHub email address for this. Note that any reviewers CC'd via the list in the PR description will not actually be sent emails.

After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail).

If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the (raw) link), then import it into your mail program. If you use GMail, you can do this via:

curl -g --user "<EMailAddress>:<Password>" \
    --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt

To iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description):

Changes since v1:
- Fixed a typo in the commit message (found by ...)
- Added a code comment to ... as suggested by ...
...

To send a new iteration, just add another PR comment with the contents: /submit.

Need help?

New contributors who want advice are encouraged to join git-mentoring@googlegroups.com, where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join.

You may also be able to find help in real time in the developer IRC channel, #git-devel on Libera Chat. Remember that IRC does not support offline messaging, so if you send someone a private message and log out, they cannot respond to you. The scrollback of #git-devel is archived, though.

gitgitgadget-git · 2026-01-23T14:00:01Z

There are issues in commit 7bb5327:
diff.tcl: Fixed alignment of tabs in git-gui diff by using spaces.

Prefixed commit message must be in lower case
The first line must be separated from the rest by an empty line

ChrisIdema · 2026-01-23T14:45:16Z

All tests passed except handle_pr_push due to "API rate limit exceeded". Don't know if that's an issue.

@Ikke can you "allow" me? Thank you in advance.

Ikke · 2026-01-23T15:50:53Z

/allow

gitgitgadget-git · 2026-01-23T15:51:31Z

User ChrisIdema is now allowed to use GitGitGadget.

ChrisIdema · 2026-01-24T13:40:53Z

/preview

gitgitgadget-git · 2026-01-24T13:41:57Z

Preview email sent as pull.2179.git.git.1769262113715.gitgitgadget@gmail.com

ChrisIdema · 2026-01-26T10:32:16Z

/preview

gitgitgadget-git · 2026-01-26T10:33:22Z

Preview email sent as pull.2179.git.git.1769423599635.gitgitgadget@gmail.com

Tabs were not properly rendered in TK regardless of tab width settings. Converting tab alignment to spaces before rendering in TK fixes this. Does not fix alignment issues in gitk. Signed-off-by: Chris Idema <github_chris_idema@proton.me>

ChrisIdema · 2026-01-26T10:41:52Z

/preview

gitgitgadget-git · 2026-01-26T10:43:00Z

Preview email sent as pull.2179.git.git.1769424177396.gitgitgadget@gmail.com

ChrisIdema · 2026-01-26T10:43:59Z

/submit

gitgitgadget-git · 2026-01-26T10:45:18Z

Submitted as pull.2179.git.git.1769424301394.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-git-2179/ChrisIdema/fix-gitgui-diff-tab-alignment-v1

To fetch this version to local tag pr-git-2179/ChrisIdema/fix-gitgui-diff-tab-alignment-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-git-2179/ChrisIdema/fix-gitgui-diff-tab-alignment-v1

gitgitgadget-git · 2026-01-26T12:27:38Z

Johannes Sixt wrote on the Git mailing list (how to reply to this email):

Am 26.01.26 um 11:45 schrieb Chris Idema via GitGitGadget:
> From: Chris Idema <github_chris_idema@proton.me>
> 
> Tabs were not properly rendered in TK regardless of tab width settings.

Sorry, I cannot reproduce what I read into this sentence. When I change
the "Tab spacing" option in the Options dialog, the display changes to
the specified tab width. I'm using Tcl/Tk 8.6.

> Converting tab alignment to spaces before rendering in TK fixes this.

Do "Stage Line/Hunk for Commit" still work after this conversion?

-- Hannes

gitgitgadget-git · 2026-01-26T12:27:40Z

User Johannes Sixt <j6t@kdbg.org> has been added to the cc: list.

ChrisIdema · 2026-01-26T13:20:31Z

git bash:

mkdir test_tabs
cd test_tabs
git init
echo "" > test.c
git add .
git commit -m "initial commit"
echo -e "int test1\t= 5;\nint test11\t= 6;\nint test111\t= 6;\n" > test.c
git gui

before fix:

after fix:

gitgitgadget-git · 2026-01-26T14:00:21Z

GitHub Chris Idema wrote on the Git mailing list (how to reply to this email):

> Sorry, I cannot reproduce what I read into this sentence. When I change
the "Tab spacing" option in the Options dialog, the display changes to
the specified tab width. I'm using Tcl/Tk 8.6.

I use git for Windows version "2.52.0.windows.1" on Windows 11.

Here is how you can reproduce the problem:
mkdir test_tabs
cd test_tabs
git init
echo "" > test.c
git add .
git commit -m "initial commit"
echo -e "int test1\t= 5;\nint test11\t= 6;\nint test111\t= 6;\n" > test.c
git gui

> Do "Stage Line/Hunk for Commit" still work after this conversion?
I'm sorry but I don't know what this means.

-- Chris

-------- Original Message --------
On Monday, 01/26/26 at 13:15 Johannes Sixt <j6t@kdbg.org> wrote:
Am 26.01.26 um 11:45 schrieb Chris Idema via GitGitGadget:
> From: Chris Idema <github_chris_idema@proton.me>
>
> Tabs were not properly rendered in TK regardless of tab width settings.

Sorry, I cannot reproduce what I read into this sentence. When I change
the "Tab spacing" option in the Options dialog, the display changes to
the specified tab width. I'm using Tcl/Tk 8.6.

> Converting tab alignment to spaces before rendering in TK fixes this.

Do "Stage Line/Hunk for Commit" still work after this conversion?

-- Hannes

gitgitgadget-git · 2026-01-26T14:00:27Z

Johannes Sixt wrote on the Git mailing list (how to reply to this email):

Am 26.01.26 um 14:32 schrieb GitHub Chris Idema:
> Here is how you can reproduce the problem:
> mkdir test_tabs
> cd test_tabs
> git init
> echo "" > test.c
> git add .
> git commit -m "initial commit"
> echo -e "int test1\t= 5;\nint test11\t= 6;\nint test111\t= 6;\n" > test.c
> git gui

So, you mean that if the tab width is set to 4, then the tab stops are
not aligned anymore?

>> Do "Stage Line/Hunk for Commit" still work after this conversion?
> I'm sorry but I don't know what this means.

These are commands in the context menu of the diff panel. They extract
the text from the widget and massage it into a patch. My suspicion is
that the patch text does not match the actual file contents, and so the
commands fail.

-- Hannes

gitgitgadget-git · 2026-01-26T15:01:20Z

GitHub Chris Idema wrote on the Git mailing list (how to reply to this email):

> So, you mean that if the tab width is set to 4, then the tab stops are not aligned anymore?

Indeed. It's probably due to the + character shifting everything by 1 character.

> My suspicion is that the patch text does not match the actual file contents, and so the commands fail.

If you select and copy the text from the window with you mouse it won't match the patch. I didn't know people used it that way. I use it as a way to review my changes before staging.
I don't know if there is a way to make it that when you copy it will copy the original text and no the modified text.
If not then we should come up with a better way to align stops.

-- Chris

-------- Original Message --------
On Monday, 01/26/26 at 14:59 Johannes Sixt <j6t@kdbg.org> wrote:
Am 26.01.26 um 14:32 schrieb GitHub Chris Idema:
> Here is how you can reproduce the problem:
> mkdir test_tabs
> cd test_tabs
> git init
> echo "" > test.c
> git add .
> git commit -m "initial commit"
> echo -e "int test1\t= 5;\nint test11\t= 6;\nint test111\t= 6;\n" > test.c
> git gui

So, you mean that if the tab width is set to 4, then the tab stops are
not aligned anymore?

>> Do "Stage Line/Hunk for Commit" still work after this conversion?
> I'm sorry but I don't know what this means.

These are commands in the context menu of the diff panel. They extract
the text from the widget and massage it into a patch. My suspicion is
that the patch text does not match the actual file contents, and so the
commands fail.

-- Hannes

gitgitgadget-git · 2026-01-26T15:01:25Z

Johannes Sixt wrote on the Git mailing list (how to reply to this email):

Am 26.01.26 um 15:43 schrieb GitHub Chris Idema:
>> So, you mean that if the tab width is set to 4, then the tab stops
>> are not aligned anymore?
> 
> Indeed. It's probably due to the + character shifting everything by 1 character.

BTW, this isn't a problem with a particular tab width. It happens with
the default width 8 as well.

>> My suspicion is that the patch text does not match the actual file
>> contents, and so the commands fail.
> 
> If you select and copy the text from the window with you mouse it
> won't match the patch. I didn't know people used it that way. I use
> it as a way to review my changes before staging.

I don't mean copy-and-paste. I mean the context menu commands. They stop
working (I suspect). This would be a show-stopper.

> I don't know if there is a way to make it that when you copy it will
> copy the original text and no the modified text. If not then we
> should come up with a better way to align stops.

I am not particularly fond of such a change. Years and years of reading
patch text has trained my brain to expect such misalignment to the
extent that even the absence of misalignment can sometimes indicate a
whitespace error.

-- Hannes

gitgitgadget-git · 2026-01-26T15:39:15Z

GitHub Chris Idema wrote on the Git mailing list (how to reply to this email):

> I am not particularly fond of such a change. Years and years of reading
patch text has trained my brain to expect such misalignment to the
extent that even the absence of misalignment can sometimes indicate a
whitespace error.

The problem is not just incorrect alignment. It's also inconsistency. In gitk the alignment is correct. In the git gui window it's not.  The best solution would be to make the git gui window behave like gitk. I thought my change only affected the way it was displayed. I'm going to see if there is a better way.

-- Chris

-------- Original Message --------
On Monday, 01/26/26 at 15:52 Johannes Sixt <j6t@kdbg.org> wrote:
Am 26.01.26 um 15:43 schrieb GitHub Chris Idema:
>> So, you mean that if the tab width is set to 4, then the tab stops
>> are not aligned anymore?
>
> Indeed. It's probably due to the + character shifting everything by 1 character.

BTW, this isn't a problem with a particular tab width. It happens with
the default width 8 as well.

>> My suspicion is that the patch text does not match the actual file
>> contents, and so the commands fail.
>
> If you select and copy the text from the window with you mouse it
> won't match the patch. I didn't know people used it that way. I use
> it as a way to review my changes before staging.

I don't mean copy-and-paste. I mean the context menu commands. They stop
working (I suspect). This would be a show-stopper.

> I don't know if there is a way to make it that when you copy it will
> copy the original text and no the modified text. If not then we
> should come up with a better way to align stops.

I am not particularly fond of such a change. Years and years of reading
patch text has trained my brain to expect such misalignment to the
extent that even the absence of misalignment can sometimes indicate a
whitespace error.

-- Hannes

gitgitgadget-git · 2026-01-26T15:39:21Z

GitHub Chris Idema wrote on the Git mailing list (how to reply to this email):

It appears inserting "apply_tab_size 1" fixes the issue. But I don't know if I'm inserting it in the right place.

-- Chris

Signed-off-by: Chris Idema <github_chris_idema@proton.me>

ChrisIdema · 2026-01-26T21:19:06Z

Why is the win + meson build failing?

ChrisIdema · 2026-01-27T13:43:04Z

/preview

gitgitgadget-git · 2026-01-27T13:44:10Z

Preview email sent as pull.2179.v2.git.git.1769521445.gitgitgadget@gmail.com

github-project-automation bot added this to Op-Amp Frequency Response and Applications Suite Jan 23, 2026

github-project-automation bot moved this to Todo in Op-Amp Frequency Response and Applications Suite Jan 23, 2026

gitgitgadget-git bot added the new user label Jan 23, 2026

ChrisIdema force-pushed the fix-gitgui-diff-tab-alignment branch from 7bb5327 to 65f38e0 Compare January 23, 2026 14:02

ChrisIdema force-pushed the fix-gitgui-diff-tab-alignment branch from 65f38e0 to 5510d35 Compare January 26, 2026 10:29

ChrisIdema force-pushed the fix-gitgui-diff-tab-alignment branch from 5510d35 to f2a09c1 Compare January 26, 2026 10:40

ChrisIdema force-pushed the fix-gitgui-diff-tab-alignment branch from 921db49 to 79fbf11 Compare January 26, 2026 18:17

ChrisIdema force-pushed the fix-gitgui-diff-tab-alignment branch from 79fbf11 to 72955cf Compare January 26, 2026 21:13

ChrisIdema marked this pull request as draft January 26, 2026 21:14

diff.tcl: call "apply_tab_size 1" to fix alignment instead of spaces

382705d

Signed-off-by: Chris Idema <github_chris_idema@proton.me>

ChrisIdema force-pushed the fix-gitgui-diff-tab-alignment branch from 72955cf to 382705d Compare January 26, 2026 21:16

diff.tcl: Fixed alignment of tabs in git-gui diff by using spaces. #2179

Are you sure you want to change the base?

diff.tcl: Fixed alignment of tabs in git-gui diff by using spaces. #2179

Conversation

ChrisIdema commented Jan 23, 2026 • edited by gitgitgadget-git bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gitgitgadget-git bot commented Jan 23, 2026

Welcome to GitGitGadget

Contributing the patches

Need help?

Uh oh!

gitgitgadget-git bot commented Jan 23, 2026

Uh oh!

ChrisIdema commented Jan 23, 2026

Uh oh!

Ikke commented Jan 23, 2026

Uh oh!

gitgitgadget-git bot commented Jan 23, 2026

Uh oh!

ChrisIdema commented Jan 24, 2026

Uh oh!

gitgitgadget-git bot commented Jan 24, 2026

Uh oh!

ChrisIdema commented Jan 26, 2026

Uh oh!

gitgitgadget-git bot commented Jan 26, 2026

Uh oh!

ChrisIdema commented Jan 26, 2026

Uh oh!

gitgitgadget-git bot commented Jan 26, 2026

Uh oh!

ChrisIdema commented Jan 26, 2026

Uh oh!

gitgitgadget-git bot commented Jan 26, 2026

Uh oh!

gitgitgadget-git bot commented Jan 26, 2026

Uh oh!

gitgitgadget-git bot commented Jan 26, 2026

Uh oh!

ChrisIdema commented Jan 26, 2026

Uh oh!

gitgitgadget-git bot commented Jan 26, 2026

Uh oh!

gitgitgadget-git bot commented Jan 26, 2026

Uh oh!

gitgitgadget-git bot commented Jan 26, 2026

Uh oh!

gitgitgadget-git bot commented Jan 26, 2026

Uh oh!

gitgitgadget-git bot commented Jan 26, 2026

Uh oh!

gitgitgadget-git bot commented Jan 26, 2026

Uh oh!

ChrisIdema commented Jan 26, 2026

Uh oh!

ChrisIdema commented Jan 27, 2026

Uh oh!

gitgitgadget-git bot commented Jan 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ChrisIdema commented Jan 23, 2026 •

edited by gitgitgadget-git bot

Loading