On Sun, 4 Jun 2006, Jakub Narebski wrote: > > > > And that shouldn't actually be that hard to do. The most trivial approach > > is to have just a pre-trigger on commits, but let's face it, that would > > not be a good "full" solution. A better one is to just make the whole > > "git update-index" thing just have a "automatically ignore CR/LF" mode. > > Why wouldn't it be good solution? The pre-commit filter thing should work fine, and hey, maybe it's worth doing that way. I just worry/think that it will result in tons of noise when you do a "git diff" and "git update-index --refresh" on a file that has been changed, but then the change reverted. But I didn't really think it through very deeply, it was just an idle "I think the pre-commit hook will fall down when X happens that is a non-commit event" thought. I suspect this is one of those things where somebody actually working in that kind of environment will figure out what the problems are, and what the righ solution is. > BTW. wouldn't Mercurial encode/decode filters > > http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter > > be a better solution than modifying files by "git update-index", > with all problems it can cause (not detected binary files, text files > which have to be in CR/LF line ending,...). Please do realize that the patch I sent out was absolutely _not_ meant to be taken seriously. It was more a "somebody could try this in a windows environment, and if it works as an approach, we can try to do it right". I'm absolutely _not_ suggesting merging that patch as-is or even in any form very close to it. It clearly needs a config file entry with filename patterns etc at a minimum. Linus - : 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