Re: gitignore design

From: Clemens Buchacher <drizzd@aon.at>
Date: Jul 30, 2011, 16:01 UTC
Message-ID: <20110730160124.GA7545@toss.lan>
In-Reply-To: <CACsJy8DcFJUK91cJm3EmHn8BMyA78gzu_pMtqJ0z9oO1RF+suw@mail.gmail.com>

On Sat, Jul 30, 2011 at 08:22:14PM +0700, Nguyen Thai Ngoc Duy wrote:

Show 10 quoted lines

> On Sat, Jul 30, 2011 at 1:45 PM, Piotr Krukowiecki
> <piotr.krukowiecki@gmail.com> wrote:
> > I was using assume-unchanged for some time but stopped after some
> > weird problems during updates. I'm not sure if this was caused by this
> > or by sparse-checkout (and I use git-svn too). Anyway, after stopping
> > using assume-unchanged and sparse-checkout mysterious problems
> > disappeared.
> 
> I'm interested in the problems you had (even better if you found a way
> to reproduce).

Hi, Same here.

Concerning the OP's question, I've also written this FAQ entry, which explains two methods to deal with the problem:

 https://git.wiki.kernel.org/index.php/GitFaq#How_do_I_tell_git_to_ignore_tracked_files.3F

It also mentions assume-unchanged and sparse checkout as a third option, but it warns that these features were not designed for that purpose. Apart from the bug fixed in aecda37 I have never had a problem with them myself. But it's not a particularly convenient solution in any case.

As far as a possible 'exclude untracked' mechanism is concerned, I am not sure that is a good thing to have. It's like saying "I want to track changes to those files, but I do not want to commit changes by default (e.g. commit -a, add -u etc.)." That may sound reasonable at first, but I think the desire to ignore changes to tracked files usually indicates a design problem. And it can almost always be solved using either option (a) or (b) from the FAQ entry above.

On the other hand, such a feature bears some risk. The repository is not guaranteed to be in a certain state, even if git status is empty. You could still have ignored changes somewhere. And it's all too easy to forget about those. I know I always forget about the rules I have in my .git/info/exclude.

Maybe I should not be trying to protect users from shooting themselves in the foot. But I would be very curious to hear from the OP why options (a) or (b) above are not a solution for his use case, before adding yet another "dangerous" mechanism to git.

Clemens