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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ