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@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html