All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Sixt <j.sixt@viscovery.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: [PATCH] gitignore: root most patterns at the top-level directory
Date: Wed, 28 Oct 2009 08:21:00 +0100	[thread overview]
Message-ID: <4AE7F0DC.6010508@viscovery.net> (raw)
In-Reply-To: <7vmy3cys0f.fsf@alter.siamese.dyndns.org>

Junio C Hamano schrieb:
> How does .cvsignore and .svnignore work?  Don't they have the same issue,
> and perhaps worse as I do not recall seeing a way to anchor a pattern to a
> particular directory like we do in their .SCMignore files?  And judging
> from the fact that they can get away with the lack of that "feature", this
> perhaps is not an issue in real life?

.cvsignore and .svnignore do not apply recursively to subdirectories, do they?

> For example, it crossed my mind that perhaps we can change the ignore
> rules so that a non-globbing pattern is automatically anchored at the
> current directly but globbing ones are recursive as before.
> 
> If we do so, there is no need to change the current .gitignore entires.
> You need to spell a concrete filename as a glob pattern that matches only
> one path if you want the recursive behaviour.  E.g. if you have a Makefile
> per subdirectory, each of which generates and includes Makefile.depend
> file, you would write "Makefile.depen[d]" in the toplevel .gitignore file.

In one project that uses autotools, I have "Makefile" and "Makefile.in" in
the top-level .gitignore. I would be forced to use this ugliness instead.

Granted, to write "/git", "/git-add", etc in .gitignore is not exactly
pretty, either, but the reason that it is so extra-ugly in the git code
itself is only because there are so many build products in a single
directory that cannot be caught by a glob pattern. In practice, you
usually have only a hand-full non-glob ignored files per directory; it
doesn't hurt to anchor them using "/frotz" style.

> But that is a kind of incompatible change whose necessity is unproven and
> has to cook and wait.

I would be concerned by this change.

-- Hannes

  reply	other threads:[~2009-10-28  7:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-27  1:10 [PATCH] gitignore: root most patterns at the top-level directory Jeff King
2009-10-28  6:03 ` Junio C Hamano
2009-10-28  7:21   ` Johannes Sixt [this message]
2009-10-30 18:24   ` Jeff King
2009-10-30 21:52     ` James Pickens

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=4AE7F0DC.6010508@viscovery.net \
    --to=j.sixt@viscovery.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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.