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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jun 4, 2010, 00:56 UTC
Message-ID: <20100604005603.GA25806@progeny.tock>
In-Reply-To: <Pine.GSO.4.63.1006031543340.22466@shipon.roxen.com>

Hi Henrik,

Henrik Grubbström wrote:

Show 6 quoted lines

> 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.)

Show 11 quoted lines

> 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.

Show 9 quoted lines

> 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