From: GitHub Chris Idema Date: Mon, 26 Jan 2026 14:43:36 GMT Subject: Re: [PATCH] diff.tcl: fixed alignment of tabs in git-gui diff by using spaces Message-ID: In-Reply-To: <07014d88-67ed-498a-8cc1-423c77972fd7@kdbg.org> > 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 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