All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Ulrich Niedermann <hun@n-dimensional.de>
To: grub-devel@gnu.org
Subject: Re: [MULTIBOOT2 SPEC PATCH v3 2/4] multiboot2: Use .gitignore files
Date: Wed, 13 May 2020 23:11:03 +0200	[thread overview]
Message-ID: <20200513231103.2794b447@n-dimensional.de> (raw)
In-Reply-To: <20200513162111.dzvtob4jpsvk2tdu@tomti.i.net-space.pl>

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).

Uli


  parent reply	other threads:[~2020-05-13 21:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08  4:50 [MULTIBOOT2 SPEC PATCH v3 0/4] multiboot2: Clean up the example kernel Hans Ulrich Niedermann
2020-05-08  4:50 ` [MULTIBOOT2 SPEC PATCH v3 1/4] multiboot2: Allow autogen.sh to run with current gnulib Hans Ulrich Niedermann
2020-05-13 16:10   ` Daniel Kiper
2020-05-08  4:50 ` [MULTIBOOT2 SPEC PATCH v3 2/4] multiboot2: Use .gitignore files Hans Ulrich Niedermann
2020-05-13 16:21   ` Daniel Kiper
2020-05-13 20:55     ` Hans Ulrich Niedermann
2020-05-13 21:11     ` Hans Ulrich Niedermann [this message]
2020-05-14  5:49       ` Hans Ulrich Niedermann
2020-05-08  4:50 ` [MULTIBOOT2 SPEC PATCH v3 3/4] multiboot2: Make example kernel build at least for i386 Hans Ulrich Niedermann
2020-05-13 16:24   ` Daniel Kiper
2020-05-14  5:26     ` Hans Ulrich Niedermann
2020-05-08  4:50 ` [MULTIBOOT2 SPEC PATCH v3 4/4] multiboot2: fix example kernel header tag alignment Hans Ulrich Niedermann
2020-05-13 16:34   ` Daniel Kiper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200513231103.2794b447@n-dimensional.de \
    --to=hun@n-dimensional.de \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.