# Extending .gitignore

2 messages from 2007-08-18 to 2007-08-18. Participants: Dmitry Kakurin, Junio C Hamano.
Thread: https://gitlist.dev/t/9567

## Dmitry Kakurin, 2007-08-18 09:43

Subject: Extending .gitignore
Message-ID: <C0E9F681E68D48EB8989022D11FEE3D1@ntdev.corp.microsoft.com>
URL: https://gitlist.dev/e/C0E9F681E68D48EB8989022D11FEE3D1%40ntdev.corp.microsoft.com

```
Currently .gitignore serves (at least) 2 purposes:
1. Specifies which files to ignore during git add
2. Specifies which files to ignore during git cleanup, but still deletes them with git cleanup -x
So it effectively splits files in 2 categories.

I always find myself with 3 categories of files:
1. Important files that I want tracked by SCM (normal files like *.c)
2. Unimportant files that I want ignored by SCM and cleaned (usually build files like *.obj, *.exe)
3. Important files that I don't want to be tracked by SCM but also I don't want them to be cleaned either (these are usually 
machine-specific config files)

So I want to be able to say to git: don't track this file, but don't delete it either (even with clean -x).
What do you think? Does it make sense? Can it be done right now?

- Dmitry 

```

## Junio C Hamano, 2007-08-18 10:00

Subject: Re: Extending .gitignore
Message-ID: <7vr6m1cgc5.fsf@gitster.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vr6m1cgc5.fsf%40gitster.siamese.dyndns.org
In-Reply-To: <C0E9F681E68D48EB8989022D11FEE3D1@ntdev.corp.microsoft.com>

```
Dmitry Kakurin <dmitry.kakurin@gmail.com> writes:

> So I want to be able to say to git: don't track this file, but don't delete it either (even with clean -x).
> What do you think? Does it make sense? Can it be done right now?

I've said that we would need .precious in addition to .ignore;
no objection at all, except "even with clean -x" part which may
be a controversial detail.

Can it be done right now?  Of course not.  That is definitely a
post 1.5.3 item.

But the beauty of the distributednes of git is that _you_ can
start working on it without disturbing anybody else nor worrying
about the stabilization freeze period.

Me, personally I would prefer to see people spending their time
to find regressions in -rc and fixing them before the release,
though...

```