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

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Henrik,

Henrik Grubbström wrote:

> I believe that users typically aren't interested in if data in the
> repository is on normalized form or not (witness the autocrlf=true
> discussion a few weeks ago, where one of the main complaints was
> that it required a renormalization (which fg/autocrlf attempts to
> solve for that specific case by not normalizing)), as long as they
> get the expected content on checkout.

I agree.  (In the case of autocrlf, it is also not very easy to
renormalize.  The usual recommendation I have seen is "git rm -r \
--cached . && git add .", which is not exactly simple.)

> This set of patches allows for an incremental, on-demand normalization.
> Eg the user could switch the attributes for a group of files from
>
>   *.bat -crlf
>
> (let's assume *.bat files use crlf linebreaks) to
>
>   *.bat -crlf text eol=crlf
>
> and then have git normalize the individual files when there's
> actually a semantic reason for a change.

... but if I understand correctly, I don’t agree with this at all.

Imagine someone with an old copy of git that does not do
normalization.  If you convert everything at once, she sees a single
enormous, semantically uninteresting cleanup patch (and she can check
the result with ‘diff -w’ or sed if suspicious).  If you wait for some
real change to piggy-back onto, on the other hand, then the per-file
normalization patches will make it hard to find what changed.

Of course, very few people use such old copies of git.  The real
problem is that git itself sees what this person would see; you are
asking to slow down everyone who tries to use diff or blame on your
repository by implicitly requiring the -w option.

> In my case, I have repositories containing files both requiring crlf
> and lf line endings, and additionally have expanded $Id$-strings
> that I want changed on first semantic change (but not before). To be
> able to use a
> git binary without this patchset I'd have to do a
> 
>   git commit -a -m 'Normalized'
> 
> as the first thing after a checkout.

The Right Thing would be to not set the relevant attributes until it
is time for the file to be normalized.  I can understand that that
might be hard and could require tool support.

This is not an argument against your patches, since I haven’t read
them (for all I know, they make everything better :)).

Regards,
Jonathan