Re: fast-import and core.autocrlf option

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 23, 2007, 03:51 UTC
Message-ID: <7vwswrojzq.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070723034514.GZ32566@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

Show 17 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Sun, 22 Jul 2007, Dmitry Kakurin wrote:
>> 
>> > It looks to me that CR/LF conversion does not happen during
>> > fast-import even if I have core.autocrlf set to 'input'.
>> > Is this a bug or is there a reason for that?
>> 
>> fast-import works on blobs only.  So it is expected.  Besides, it would 
>> slow down fast-import tremendously if you wanted to introduce that 
>> behaviour.  Therefore I suggest just rolling your own dos2unix instead of 
>> trying to play cute games with fast-import.
>
> Right, in fast-import we only process blobs as raw blobs.
> Its rare that we have a file path associated with the blob data
> at the time that we are actually processing the blob itself.  E.g.
> applications can send us blobs up front, before they even start to
> send us commits and path information.

Don't the front-ends usually have path information already when they feed you a blob data, especially most of them operate on per-file history? If that is the case,...

> So if we were to offer the CRLF->LF conversion feature in fast-import
> it would need to be an option supplied at the time the 'data'
> command issued, rather than based upon the gitattributes system
> that is normally used for working tree operations.

... the "option" could be "this came from such and such path" instead of "this is DOS data, please apply crlf".