Re: Importing Mozilla CVS into git

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 4, 2006, 17:55 UTC
Message-ID: <Pine.LNX.4.64.0606041050010.5498@g5.osdl.org>
In-Reply-To: <e5u0o0$3rm$1@sea.gmane.org>

On Sun, 4 Jun 2006, Jakub Narebski wrote:

Show 7 quoted lines

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

Show 7 quoted lines

> 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