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

[Jonathan Nieder <jrnieder@gmail.com>]

Henrik Grubbström wrote:
> On Thu, 3 Jun 2010, Jonathan Nieder wrote:

>> 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.
>
> This seems more like an argument against repositories where
> renormalizations have occurred, than against the feature as such.

No, it is an argument against making the process of renormalization
more painful than it has to be (and against piggy-backing in general).
It is kindest to have a flag day and yank the carriage returns off all
at once like a bandage.

> Well, diff and blame would be confused by a crlf renormalization
> regardless of whether the renormalization was piggy-backed or not.

Only if they cross the revision where renormalization occurred.

> I did do an experiment with a .gitattributes file like:
> 
>   *.c crlf ident
>   [attr]foreign_ident -ident block_commit=Remove-foreign_ident-attribute-before-commit.
>   # A list of files that haven't been changed since import follows.
>   /foo.c foreign_ident
>   /bar.c foreign_ident
>   # etc

This looks more sane.  Ident strings usually touch only a few lines.

> there were two problems in addition to the long
> list of files in the .gitattributes file:
> 
>   * The attributes file parsing was broken (recently fixed in the
>     master branch), and the above actually caused foo.c and bar.c
>     to have the ident attribute.

Wouldn’t something like

 /foo.c -ident has_foreign_ident

work?  (Thanks for fixing that attributes macro processing bug, btw.)

>   * Hooks are not copied by git clone. Support for copying of hooks
>     to non-POSIX-like systems is not something I'd like to attempt.

Can’t you include a hooks/pre-commit file and a HACKING file: "copy
this file to .git/hooks if you want your patches to be accepted"?

Thanks for your hard work,
Jonathan