On Tue, Jun 08, 2010 at 05:52:37PM +0200, Henrik Grubbström wrote: > [...] > True, there's no problem before the attribute change, but there is for > commits between the attribute change and when the repository got > normalized (which can be a while with the current git). As you say, the current git makes it easy to commit something where the attributes and the contents do not match. I think this needs to be fixed, and that your proposed patch in relaxed mode makes the problem _worse_, since it will then take even longer before these commits are fixed. But see below. > > Re: configuration option naming: > > I've settled for core.normalizationPolicy, with the values > 'strict' (default) for the behaviour requested by you and Jonathan, > and 'relaxed' for my initial behaviour. The name might be a bit vague, maybe there are other things that could be normalized? Maybe adding the word "index" is an improvement - e.g. core.indexNormalizationPolicy or just core.indexNormalization. > > Teaser: > [...] > $ git status > # On branch master > nothing to commit (working directory clean) > $ cat >.gitattributes > * ident > $ git status > [...] > # modified: expanded-keywords > [...] > > $ git config core.normalizationPolicy relaxed > $ git status > # On branch master > [No longer modified] THIS behaviour is what I find scary. In this case, "ident" is clearly a newly added attribute, and git should not hide this from you. If you add a mode where git will hide this permanently, chances are the repositories will never be fixed. The ident attribute may be a bit special since in your case it is only supposed to change if some other contents in the file change as well, but please also think how this will work with the text/eol attributes. Setting the text attribute and then having to CHANGE a file before getting it normalized is not good. Still, I think your original problem description of cloning something and ending up with a dirty tree is indeed an annoying problem. So what about having the relaxed mode behave as follows: If both of these are true: - the current attributes for a file are the same as it is registered as in the index with your new patch - a checkout of the file would result in identical contents to what is currently in the working directory Then behave as if the file is not modified. Or, in other words: If attributes are unchanged, a file is unmodified not only if it would result in the same contents after being added, but also if it would result in the current working directory contents after being checked out again. This should work for both text and ident on clone at least. - Finn Arne -- 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