On Wed, 9 Jun 2010, Finn Arne Gangstad wrote:
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.
Hmm... Maybe.
Teaser:
[...]
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.
True.
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.
Ok, so the expanded-keywords file in the example should show up as
modified in relaxed mode as well, but be cleaned if the modified
attributes file is added to the index? Or only after being committed?
This should work for both text and ident on clone at least.
I'll see what I can do...
Currently, I'm trying to understand the semantic difference between
ce_modified() and ce_match_stat().
--
Henrik Grubbström grubba@xxxxxxxxxx
Roxen Internet Software AB grubba@xxxxxxxxx