linux-kernel - Re: [PATCH v2] kbuild: gitignore output directory

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: <CAK7LNAT3Yf1_3L77VNjtcr5SP2eM0x19hid0J45PcHqf8Fwcwg@mail.gmail.com>
Date:   Sun, 24 Mar 2019 11:22:11 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Andre Przywara <andre.przywara@....com>
Cc:     Vladimir Kondratiev <vladimir.kondratiev@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] kbuild: gitignore output directory

On Sat, Mar 23, 2019 at 12:53 AM Andre Przywara <andre.przywara@....com> wrote:
>
> Hi,
>
> > When compiling into output directory using O=, many files
> > created under KBUILD_OUTPUT that git considers
> > as new ones; git clients, ex. "git gui" lists it, and it clutters
> > file list making it difficult to see what was really changed
> >
> > Generate .gitignore in output directory that ignores all
> > its content
>
> just found this when testing -rc1.
> Unfortunately this breaks my setup, because I keep a totally separate
> git repository in my build directories to track (various versions of)
> .config. So .gitignore there is carefully crafted to ignore most build
> artefacts, but not .config, for instance.
>
> I am not sure how git would interact with the build directory for you?
> Do you build into a subdirectory of the kernel tree?
>
> I was hoping that we would not overwrite unrelated files in directories
> outside of the kernel tree. In case this is about a subdirectory of the
> source tree, can we somehow check for this case?


I am not sure if it is worthwhile
adjusting the upstream kernel to
the workflow of an individual like this.

If it is, we could like this:

outputmakefile:
ifneq ($(KBUILD_SRC),)
        $(Q)ln -fsn $(srctree) source
        $(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkmakefile $(srctree)
        $(Q)test -e .gitignore || \
        { echo "# this is build directory, ignore it"; echo "*"; } > .gitignore
endif


> Cheers,
> Andre.
>
> >
> > Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@...ux.intel.com>
> > Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
> > ---
> >  Makefile | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/Makefile b/Makefile
> > index 97ee0be24d52..d487fca342c4 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -483,10 +483,13 @@ PHONY += outputmakefile
> >  # outputmakefile generates a Makefile in the output directory, if using a
> >  # separate output directory. This allows convenient use of make in the
> >  # output directory.
> > +# At the same time when output Makefile generated, generate .gitignore to
> > +# ignore whole output directory
> >  outputmakefile:
> >  ifneq ($(KBUILD_SRC),)
> >       $(Q)ln -fsn $(srctree) source
> >       $(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkmakefile $(srctree)
> > +     $(Q){ echo "# this is build directory, ignore it"; echo "*"; } > .gitignore
> >  endif
> >
> >  ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),)
> > --
> > 2.17.1
>


-- 
Best Regards
Masahiro Yamada