From: Bruce Stephens <bruce.stephens@isode.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alex Riesen <raa.lkml@gmail.com>, git@vger.kernel.org
Subject: Re: refining .gitignores
Date: Thu, 15 Nov 2007 21:13:04 +0000 [thread overview]
Message-ID: <807ikjdxgf.fsf@tiny.isode.net> (raw)
In-Reply-To: <alpine.LFD.0.9999.0711151237550.4260@woody.linux-foundation.org> (Linus Torvalds's message of "Thu\, 15 Nov 2007 12\:40\:14 -0800 \(PST\)")
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 15 Nov 2007, Bruce Stephens wrote:
>>
>> They are in the index. What I want is a list of files which are known
>> to git, which are matched by the default rules (in particular the
>> .gitignore files).
>
> Ahh.
>
> *All* the .gitignore rules are purely about files that git does not
> already know about. Once git tracks a pathname, the ignore rules simply
> do not matter.
>
> Files that are in the index are simply never ignored. There's no way to
> ignore them, and in fact, the whole "git add -f" thing is a way to add
> files to the index and override the exclude rules - at which point git
> then tracks them regardless of any such exclude rules.
OK. I think I sort of understood that, but it's nice to have it
clearly stated.
I'm not worried so much about files that already exist. I'm worried
that we may in the future create files that we want to store in git
and which are ignored. If we do that there's a chance we'll miss them
(because "git gui", "git status", etc., won't bring attention to
them).
So it seemed valuable to try to make the .gitignore patterns precise:
so that they ignore all the generated files that our builds produce,
while not matching any files that git knows about.
That certainly wouldn't guarantee that new files wouldn't be caught by
the patterns, but it ought to lower the probability of this, since
there's a decent chance that such files will either be not touched by
the patterns (because they're *.java or something), or they'll fit
into one of the already handled exceptions (Doxyfile.local is one:
most *.local files are build products, but Doxyfile.local aren't).
I guess if you're starting off with some project in git then this
isn't such an issue: you evolve the patterns and the build process and
so on in parallel. So maybe there's not such a demand for finding
this information, and those of us who do want to do it are best using
the "git add" loop approach?
next prev parent reply other threads:[~2007-11-15 21:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-14 22:36 refining .gitignores Bruce Stephens
2007-11-14 23:02 ` Alex Riesen
2007-11-15 11:39 ` Bruce Stephens
2007-11-15 19:26 ` Alex Riesen
2007-11-15 20:28 ` Bruce Stephens
2007-11-15 20:40 ` Linus Torvalds
2007-11-15 21:13 ` Bruce Stephens [this message]
2007-11-15 21:17 ` Alex Riesen
2007-11-15 21:56 ` Linus Torvalds
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=807ikjdxgf.fsf@tiny.isode.net \
--to=bruce.stephens@isode.com \
--cc=git@vger.kernel.org \
--cc=raa.lkml@gmail.com \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).