Re: [PATCH v4 0/5] Patches to avoid reporting conversion changes.

[Finn Arne Gangstad <finnag@pvv.org>]

On Sun, Jun 06, 2010 at 12:50:08PM +0200, Henrik Grubbström wrote:
[...]
>
> Currently (as I believe you know), git has no detection of when the  
> conversion mode for a file has changed, and it might even take a while  
> before the users notice that the repository is not normalized. eg:
>
>   0) There's a repository with some files containing crlf line endings.
>
>   1) User A notices that git now has native support for crlf
>      line endings, and adds the attribute eol=crlf for the
>      affected files.
>
>   2) User A does a git status, sees that .gitattributes is
>      modified, and commits it.

I think it would be best if git at this time could decide that the
affected files also become dirty. The ideal commit is one that
both alters the .gitattributes _and_ the affected files at the same
time, and git should make it easy to create that commit.

> [...]
>   6) User C is new to the project and does an initial git clone,
>      and ends up with a dirty index.

And the reason for this is mostly that unless you perform some special
actions, you will commit attributes and contents that are mismatched.

In your suggested mode, whay would happen if you did this:

$ git clone ......  (which has files that are "wrong" wrt line endings and
attributes for some .c files)
$ touch *.c

Would it still believe all *.c files were clean? Does it require an
actual other change at the same time to allow you to normalize the
file? That would be detrimental I think.  Changing newlines is best
done as a separate commit, intermingling newline changes and real
changes in the same commmit is not where you want to go.

However, for your ID string you obviously want this behaviour. I'm
guessing that hook is alreasy set up so that if you just touch the
file, it will still be treated as unmodified?

>
> What my patch set achieves is that user C above also gets a clean index.
>
> What it seems you want is that user A above should have all files that 
> got denormalized by the attribute change marked dirty at 2 (and 3).

That would indeed be a very welcome change.

> As I believe both behaviours may be desireable a config option and/or  
> attribute is needed. Any suggestions for a name (and default value)?

I think the default behaviour should be to mark files dirty if there
are ANY attribute changes that could cause content changes done to
them at all. I'm not sure that is exactly what your patch series is
allowing us to track though?

Just to be clear:

If you add this to your .gitattributes

*.c eol=lf

I think it would be very helpful if git then would treat all .c files
as "stat-dirty" the next time it updates its index.

A for config variables, what about:

core.rereadOnAttributeChanges = [true]/false    (default = true)

Which makes some sense for detecting it in 2, but not so much for
ignoring it in 6.

- Finn Arne