On Wed, 14 Feb 2007, Johannes Sixt wrote:
quoted text
>
> Thanks a lot, busy beaver! I gave this a quick spin with a few
> interesting operations: merges and rebase. Merges leave the merge
> results with only LFs behind.

Yes. Merge uses "git-cat-file" (well, it historically did, now that it's 
built-in it still does the equivalent operation).

I already talked about how git-cat-file was special ;)

quoted text
> Rebasing seems to work as expected (working files have CRLFs), except 
> when merges are needed.

Well, it always "merges", but yes, you mean three-way data merges. The 
normal SHA1-direct merges will just use the normal git-read-tree thing 
which is the same as checkout.

quoted text
> Doesn't git-unpack-file also need to call into the converter?

See earlier discussions. git-cat-file (and git-unpack-file, which is just 
a version of it, really) don't have the original filename, so we'll need 
to extend on it some way in order to support file attributes even in 
theory. So before we do that, I'd hate to do any format conversion there.

Yes, yes, right now it ignores the filename *anyway*, but the point is, 
right now that's a "small implementation detail". I would NOT want to do 
this if I couldn't know the filename at all!

The merge algorithms actually obviously *do* know the filename fo the 
things that they are going to merge, so the filename information does 
exists. It's just not passed on far enough.

Finally, one comment: if you use "autocrlf = input" (my second patch), all 
of this works even now, since the default is to just leave things as 
LF-only anyway. In fact, even with "autocrlf = on", nothing should really 
*break* except for silly editors that actuall *require* CRLF.

IOW, it's more important to do the CRLF->LF conversion than it is to do 
the LF->CRLF one ;)

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html