Re: gitignore design

[Clemens Buchacher <drizzd@aon.at>]

On Sat, Jul 30, 2011 at 08:22:14PM +0700, Nguyen Thai Ngoc Duy wrote:
> 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