From: Junio C Hamano Date: Mon, 23 Jul 2007 03:51:37 GMT Subject: Re: fast-import and core.autocrlf option Message-ID: <7vwswrojzq.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20070723034514.GZ32566@spearce.org> "Shawn O. Pearce" writes: > Johannes Schindelin 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".