linux-kernel - Overly aggressive .gitignore file?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wiJHMje8cpiTajqrLrM23wZK0SWetuK1Bd67c0OGM_BzQ@mail.gmail.com>
Date:   Tue, 4 Jul 2023 12:49:01 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     Nicolas Schier <nicolas@...sle.eu>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Overly aggressive .gitignore file?

So this keeps happening to me - I go to apply a patch I just
downloaded with 'b4', and I do my regular

     git am -s --whitespace 2023<tab>

and the dang thing doesn't autocomplete.,

The reason it doesn't auto-complete ends up being that my kernel tree
contains some other random stale mbx file from the _previous_ time I
did that, because they effectively get hidden from "git status" etc by
our .gitignore file.

So then those stale files end up staying around much too long and not
showing up on my radar even though they are just old garbage by the
time I have actually applied them.

And I always use auto-complete, because those filenames that 'b4'
generate are ridiculously long (for good reason).

And the auto-complete always fails, because b4 just uses a common
prefix pattern too (again, for a perfectly good reason - I'm not
complaining about b4 here).

This has been a slight annoyance for a while, but the last time it
happened just a moment ago when I applied David Howells' afs patch
(commit 03275585cabd: "afs: Fix accidental truncation when storing
data" - not that the particular commit matters, I'm just pointing out
how it just happened _again_).

So I'm really inclined to just revert the commit that added this
pattern: 534066a983df (".gitignore: ignore *.cover and *.mbx"). It's
actively detrimental to my workflow.

I'm not sure why that pattern was added, though. These are not
auto-generated files from our build.  So before I go off and revert
it, let's ask the people mentioned in that commit.

I *suspect* the thing that triggered this wasn't that people actually
wanted to ignore these files, but that it was related to the misguided
"let's use .gitignore to build source packages" project.

But at least for me, it's a real problem when .gitignore contains
other files than the ones we actually generate.

The only one that actually commonly affects me is the *.mbx file,
although I could certainly see the same being true of the *.cover
thing.

And there might certainly be other patterns like this that I just
don't react to, because they don't have the same detrimental effects
on how I work.

Comments?

               Linus