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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html