linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK7LNARM04vuv7o+GJ082140efWCCN-q7jCaacrA_DT=FuoUWQ@mail.gmail.com>
Date:   Wed, 5 Jul 2023 14:04:05 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Nicolas Schier <nicolas@...sle.eu>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Overly aggressive .gitignore file?

On Wed, Jul 5, 2023 at 12:46 PM Nicolas Schier <nicolas@...sle.eu> wrote:
>
> On Tue 04 Jul 2023 12:49:01 GMT, Linus Torvalds wrote:
> > 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
>
> Thanks for sharing some details of your concrete workflow.  I think,
> having this in mind, it is quite a fair point to criticise the handling
> (or ignoring, respectively) of files that are are not generated or used
> during kernel builds.  But in general, I don't find it that easy to
> draw the line; should we also remove
>
>    *.kdev4
>    *.orig
>    *.patch
>    *~
>    \#*#
>    patches
>    series
>
> from .gitignore?   I don't think so, even though they (partially) fall
> into the same category.
>
> From my point of view, this is a decision of personal preference.
> I do like the ignoring of *.mbx and *.cover, as I tend to have those
> files around for some time by intention.  But a revert would not cause
> any trouble to me and optimisation of your workflow is magnitudes more
> important, so I am perfectly fine with it, if you want to have the
> commit reverted.


Already reverted.
(d528014517f2b0531862c02865b9d4c908019dc4)

I also chimed-in too late.

If he wants to hear opinions from people
who live in different time zones, he can wait
for 24 hours, but his decision is usually quick.



-- 
Best Regards
Masahiro Yamada