Re: [MULTIBOOT2 SPEC PATCH v3 2/4] multiboot2: Use .gitignore files

[Hans Ulrich Niedermann <hun@n-dimensional.de>]

On Wed, 13 May 2020 23:11:03 +0200
Hans Ulrich Niedermann <hun@n-dimensional.de> wrote:

> On Wed, 13 May 2020 18:21:11 +0200
> Daniel Kiper <dkiper@net-space.pl> wrote:
> 
> > On Fri, May 08, 2020 at 06:50:47AM +0200, Hans Ulrich Niedermann
> > wrote:  
> > > Add .gitignore file and remove the obsolete .bzrignore file.
> > >
> > > The doc/.gitignore file is generated by gnulib-tool so we keep
> > > that file in addition to the top-level .gitignore file which
> > > covers everything else in the subdirectory tree.    
> > 
> > If it is generated by gnulib-tool why do we need to create it?  
> 
> The alternatives to adding doc/.gitignore to the version controlled
> files are to either
> 
>   a) have the top-level .gitignore file ignore "/doc/.gitignore"
> 
>   b) have the gnulib-generated doc/.gitignore file just flying around,
>      neither .gitignored like all other generated files, nor under
>      version control
> 
> Option a) sounds like the beginning of a road into world of very weird
> and unexpected things, and option b) defeats the purpose of having any
> .gitignore or .bzrignore etc. files at all.
> 
> I much prefer ignoring a few patterns which gnulib is considering
> useful to be ignored at this time by adding doc/.gitignore. Well, now
> that I am thinking about this...
> 
>   c) Maybe gnulib would recognize when the top-level .gitignore files
>      does the job gnulib would create the doc/.gitignore file for.
> Then we would just have two more patterns in our top-level .gitignore
>      file, and gnulib would not create a doc/.gitignore file.
> 
> I will have to investigate option c). I would prefer that over my
> original option from the patch (adding the doc/.gitignore file as
> generated by gnulib).

No luck here. I have just examined what gnulib-tool does in the presence
of the proper patterns having been added to the top-level .gitignore
file with an absent doc/.gitignore file: gnulib-tool creates a new file
doc/.gitignore to which it adds its patterns.

So option c) is out, option a) and option b) both create unnecessary
friction in the day to day use of git, I am therefore still convinced
the best way to go is to have a top-level .gitignore with our own stuff,
and a doc/.gitignore file with whatever patterns gnulib-tool wants to
put in there together with the scripts it puts into doc/.

Note that gnulib-tool creates a few more subdirectory .gitignore files
in /lib/ and /m4/. We just do not notice those as we .gitignore the
whole subdirectory for those two anyway. The only thing from gnulib we
are interested in are the scripts generating HTML from
doc/multiboot.texi, not m4 macros or C source files.

Uli