git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: /* in .gitignore

From
HWHilco Wijbenga <hilco.wijbenga@gmail.com>
Date
Sep 26, 2012, 00:03 UTC
Message-ID
<CAE1pOi2kU0dAqZVDwJAG9frG4Oq4rswtE85AL2Mk9eNCjRHhGg@mail.gmail.com>
In-Reply-To
<7vobktvgq8.fsf@alter.siamese.dyndns.org>
On 25 September 2012 16:13, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
>
>> Naturally, this behaviour makes perfect sense: "/*" means everything.
>> Still, I was wondering whether it might be a good idea to make an
>> exception for '.gitignore' itself? Then if somebody *really* wanted to
>> ignore '.gitignore' they could add "/.gitignore" to '.gitignore'?
>
> If somebody is sick enough to ignore "everything", he can add "/*"
> to the .gitignore file and in order to make sure he knows what he is
> doing and he is doing what he thinks is doing, he would check with
> "git diff --stat HEAD" etc. before committing, and double check with
> "git show --stat" etc. after committing.

Ignoring everything is not quite so "sick". :-) My use case is Eclipse's .metadata directory. This directory is *huge* but only .metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs is really of interest (and not even all of those files). The subset of *.prefs that we are interested in will allow us to share Eclipse configuration settings (things like formatting settings and which warnings we care about). So I have several '.gitignore' files with "/*" + "!/some-dir/". [To make things even more interesting, the ".settings" directory should be ignored in all other places (so it's in our top level '.gitignore').]

I would be very happy to find out better ways to handle this particular scenario. I had quite a struggle getting it to work.

Show 6 quoted lines
> ".gitignore" (or ".gitattributes" for that matter) shouldn't be any
> different from your ordinary tracked contents.  If you have "*.o" in
> the ignored pattern list, you would need an extra care to defeat the
> pattern to add vendor-supplied binary-only object file with "add -f"
> and live with the fact that a new vendor-supplied binary-only object
> file not appearing on untracked list.  It is exactly the same deal.

I do not entirely agree. I think '.gitignore' *is* different. This file is special and affects Git's behaviour. And it does so *before* it has been committed. Or even added. The fact that '.gitignore' itself is not listed in the output of, e.g., "git status" is easy to miss.

I have not really used '.gitattributes' but I assume the same applies.
> Having said that, I guess you could add "!.git*" to your
> $GIT_DIR/info/exclude and see if it gives an improved user
> experience.
Mmm, that does not seem to help. I did

git init && touch file.txt && echo '/*'>.gitignore && echo '!.gitignore' >>.git/info/exclude && git status

it lists nothing (Git 1.7.12). I had expected to see '.gitignore'. Did I misunderstand you?

Even so, this would only improve *my* user experience, wouldn't it? This would not get pushed to the central repository so it would not help anyone else.

Previous: Junio C Hamano
Message 3 of 3 in “/* in .gitignore”
  1. Hilco WijbengaSep 25, 2012
  2. Junio C HamanoSep 25, 2012
  3. Hilco WijbengaSep 26, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.