Bug Report: Superfluous Tab Characters

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]

Hi Diogo,

On Fri, 3 Feb 2023 at 13:50, Diogo Fernandes <diogoabfernandes@gmail.com> wrote:

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

On Sat, 4 Feb 2023 at 13:54, Diogo Fernandes <diogoabfernandes@gmail.com> wrote:

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

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 <martin.agren@gmail.com> wrote: