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@xxxxxxxxx> wrote: > > On Sat, 4 Feb 2023 at 13:54, Diogo Fernandes <diogoabfernandes@xxxxxxxxx> wrote: > > On Fri, 3 Feb 2023 at 14:43 Martin Ågren <martin.agren@xxxxxxxxx> wrote: > >> > >> On Fri, 3 Feb 2023 at 13:50, Diogo Fernandes <diogoabfernandes@xxxxxxxxx> 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
