# Bug Report: Superfluous Tab Characters 4 messages from 2023-02-03 to 2023-02-05. Participants: Diogo Fernandes, Martin Ågren. Thread: https://gitlist.dev/t/59188 ## Diogo Fernandes, 2023-02-03 12:29 Subject: Bug Report: Superfluous Tab Characters Message-ID: URL: https://gitlist.dev/e/CADPR2CUgrO6ius5ss9Mgk8Zktf%2B4zQDq0vP4EEKOMku7K%3DV6FA%40mail.gmail.com ``` Dear git team, I have run into a bug where git seems to be adding superfluous tabs to the end of filenames that contain a space. I have attached the output of `git bugreport` for your review. Feel free to have a look https://github.com/trufflesecurity/trufflehog/issues/1060 for additional context. Thanks. Regards, Diogo Fernandes Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue. What did you do before the bug happened? (Steps to reproduce your issue) $ mkdir test $ cd test $ git init $ echo foo > "filename 2" $ git add "filename 2" $ git commit -m "test" $ git log -p | grep "+++" | xxd # 0x09 is a \t character that is being added to a filename with a space 00000000: 2b2b 2b20 622f 6669 6c65 6e61 6d65 2032 +++ b/filename 2 00000010: 090a .. What did you expect to happen? (Expected behavior) $ echo "foo" > filename2 4 git add . $ git commit -m "test" $ git log -p | grep "+++" | xxd 00000000: 2b2b 2b20 622f 6669 6c65 6e61 6d65 320a +++ b/filename2. What happened instead? (Actual behavior) A tab character is being appended to filenames. What's different between what you expected and what actually happened? A tab character should not be appended to filenames. Anything else you want to add: No. Please review the rest of the bug report below. You can delete any lines you don't wish to share. [System Info] git version: git version 2.39.1 cpu: arm64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh feature: fsmonitor--daemon uname: Darwin 21.6.0 Darwin Kernel Version 21.6.0: Mon Dec 19 20:43:09 PST 2022; root:xnu-8020.240.18~2/RELEASE_ARM64_T6000 arm64 compiler info: clang: 14.0.0 (clang-1400.0.29.202) libc info: no libc information available $SHELL (typically, interactive shell): /bin/zsh [Enabled Hooks] ``` ## Martin Ågren, 2023-02-03 13:43 Subject: Re: Bug Report: Superfluous Tab Characters Message-ID: URL: https://gitlist.dev/e/CAN0heSqwVV_G_nrt%3DomK0UjXVAD%2BTYPC%2BoB-1xHF4dG4oovncA%40mail.gmail.com In-Reply-To: ``` Hi Diogo, On Fri, 3 Feb 2023 at 13:50, Diogo Fernandes wrote: > > I have run into a bug where git seems to be adding superfluous tabs to > the end of filenames that contain a space. I have attached the output > of `git bugreport` for your review. Feel free to have a look > https://github.com/trufflesecurity/trufflehog/issues/1060 for > additional context. The code that adds this tab in the output of `git log` and friends has changed a bit since it was originally added in 1a9eb3b9d5 ("git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)", 2006-09-22), but in that commit you can see the original motivation. Here's an online view: https://github.com/git/git/commit/1a9eb3b9d50367bee8fe85022684d812816fe531 Martin ``` ## Martin Ågren, 2023-02-05 15:28 Subject: Re: Bug Report: Superfluous Tab Characters Message-ID: URL: https://gitlist.dev/e/CAN0heSruSHQk8cPZ1-Zhp8dfL%2Bj-OAsASrsBTVdWKQcx14Pxtw%40mail.gmail.com In-Reply-To: ``` On Sat, 4 Feb 2023 at 13:54, Diogo Fernandes wrote: > On Fri, 3 Feb 2023 at 14:43 Martin Ågren wrote: >> >> On Fri, 3 Feb 2023 at 13:50, Diogo Fernandes wrote: >> > >> > I have run into a bug where git seems to be adding superfluous tabs to >> > the end of filenames that contain a space. I have attached the output >> > of `git bugreport` for your review. Feel free to have a look >> > https://github.com/trufflesecurity/trufflehog/issues/1060 for >> > additional context. >> >> The code that adds this tab in the output of `git log` and friends has >> changed a bit since it was originally added in 1a9eb3b9d5 >> ("git-diff/git-apply: make diff output a bit friendlier to GNU patch >> (part 2)", 2006-09-22), but in that commit you can see the original >> motivation. > So, this is by design and not a bug? And is it still current in the latest version of git? Yes, it appears to be by design: Somebody was wondering on #git channel why a git generated diff does not apply with GNU patch when the filename contains a SP. It is because GNU patch expects to find TAB (and trailing timestamp) on ---/+++ (old_name and new_name) lines after the filenames. The "diff --git" output format was carefully designed to be compatible with GNU patch where it can, but whitespace characters were always a pain. This adds an extra TAB (but not trailing timestamp) to old_name and new_name lines of git-diff output when the filename has a SP in it. An earlier patch updated git-apply to prepare for this. From a quick test, this behavior does seem to be in newest git. I sense there is some sort of ulterior motive here that hasn't come across yet. Are you trying to parse the output of `git log` to find something? Would `git diff-tree` work, e.g., if you're mostly just after the filenames involved? Depending on what you're trying to achieve, it could be a bit simpler to parse `git diff-tree` and other "plumbing" commands, rather than `git log` and other such "porcelain" commands. (Also, note that one person's `git log` output can be different from yours, e.g., because of various config knobs being set different ways.) Martin ``` ## Diogo Fernandes, 2023-02-05 17:01 Subject: Re: Bug Report: Superfluous Tab Characters Message-ID: URL: https://gitlist.dev/e/CADPR2CWzjiPJn9ZtkcU0ZTbacq5JQu2vXriuLq%2BVreqqUo_-dA%40mail.gmail.com In-Reply-To: ``` Hi Martin, I am not personally parsing the output of git. This was rather observed while using a third-party tool that reads the output of git as initially pointed out by https://github.com/trufflesecurity/trufflehog/issues/1060. I have the latest v2.39.1 from `brew` on macOS and the tab character is added to the output. Anyhow, thanks for checking. Regards, Diogo On Sun, Feb 5, 2023 at 4:28 PM Martin Ågren wrote: > > On Sat, 4 Feb 2023 at 13:54, Diogo Fernandes wrote: > > On Fri, 3 Feb 2023 at 14:43 Martin Ågren wrote: > >> > >> On Fri, 3 Feb 2023 at 13:50, Diogo Fernandes wrote: > >> > > >> > I have run into a bug where git seems to be adding superfluous tabs to > >> > the end of filenames that contain a space. I have attached the output > >> > of `git bugreport` for your review. Feel free to have a look > >> > https://github.com/trufflesecurity/trufflehog/issues/1060 for > >> > additional context. > >> > >> The code that adds this tab in the output of `git log` and friends has > >> changed a bit since it was originally added in 1a9eb3b9d5 > >> ("git-diff/git-apply: make diff output a bit friendlier to GNU patch > >> (part 2)", 2006-09-22), but in that commit you can see the original > >> motivation. > > > So, this is by design and not a bug? And is it still current in the latest version of git? > > Yes, it appears to be by design: > > Somebody was wondering on #git channel why a git generated diff > does not apply with GNU patch when the filename contains a SP. > It is because GNU patch expects to find TAB (and trailing timestamp) > on ---/+++ (old_name and new_name) lines after the filenames. > > The "diff --git" output format was carefully designed to be > compatible with GNU patch where it can, but whitespace > characters were always a pain. > > This adds an extra TAB (but not trailing timestamp) to old_name > and new_name lines of git-diff output when the filename has a SP > in it. An earlier patch updated git-apply to prepare for this. > > From a quick test, this behavior does seem to be in newest git. > > I sense there is some sort of ulterior motive here that hasn't come > across yet. Are you trying to parse the output of `git log` to find > something? Would `git diff-tree` work, e.g., if you're mostly just after > the filenames involved? Depending on what you're trying to achieve, it > could be a bit simpler to parse `git diff-tree` and other "plumbing" > commands, rather than `git log` and other such "porcelain" commands. > > (Also, note that one person's `git log` output can be different from > yours, e.g., because of various config knobs being set different ways.) > > Martin ```