Re: Importing Mozilla CVS into git

From: Robin Rosenberg (list subscriber) <robin.rosenberg.lists@dewire.com>
Date: Jun 4, 2006, 19:44 UTC
Message-ID: <200606042144.45385.robin.rosenberg.lists@dewire.com>
In-Reply-To: <Pine.LNX.4.64.0606041050010.5498@g5.osdl.org>

söndag 04 juni 2006 19:55 skrev Linus Torvalds:

Show 31 quoted lines

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

Other version control systems simply treat text and binary files differently. No smart(ass) logic doing the wrong thing. A text file gets processed on check-in AND checkout depending on it's type and the client setting. Some heuristics may be applied when adding files. i.e look-up according to magic cookies or looking for bytes that simply do not occur in text files (e..g a nul byte). Those few systems that I know about treat the type as a file (as opposed to a version specific) attribute. Some systems have lots of file types, not just text and binary. Encoding is about the only thing that would interest me, although not terribly important (except the file name), but that may be off topic for this thread.

The hash-on-the whole-tree might be a reason for making the attribute version-specific.

Mercurial's filters sounds like a good way to implement file types in a generic way as long as git's excellent performance isn't hurt.

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

Do people apply your patches right away, like it's some god-like commandments?

-- robin