{"thread":{"id":"9161","subject":"fast-import and core.autocrlf option","startedAt":"2007-07-22T22:59:26Z","lastAt":"2007-07-23T04:01:33Z","messageCount":5,"participants":["Dmitry Kakurin","Johannes Schindelin","Shawn O. Pearce","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"48234","messageId":"a1bbc6950707221559m63fb1295jc26b1327e71687e3@mail.gmail.com","threadId":"9161","inReplyTo":null,"subject":"fast-import and core.autocrlf option","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-07-22T22:59:26Z","receivedAt":"2007-07-22T22:59:26Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"It looks to me that CR/LF conversion does not happen during\nfast-import even if I have core.autocrlf set to 'input'.\nIs this a bug or is there a reason for that?\n"},{"id":"48241","messageId":"Pine.LNX.4.64.0707230039560.14781@racer.site","threadId":"9161","inReplyTo":"a1bbc6950707221559m63fb1295jc26b1327e71687e3@mail.gmail.com","subject":"Re: fast-import and core.autocrlf option","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-22T23:41:02Z","receivedAt":"2007-07-22T23:41:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 22 Jul 2007, Dmitry Kakurin wrote:\n\n> It looks to me that CR/LF conversion does not happen during\n> fast-import even if I have core.autocrlf set to 'input'.\n> Is this a bug or is there a reason for that?\n\nfast-import works on blobs only. So it is expected. Besides, it would \nslow down fast-import tremendously if you wanted to introduce that \nbehaviour. Therefore I suggest just rolling your own dos2unix instead of \ntrying to play cute games with fast-import.\n\nCiao,\nDscho\n"},{"id":"48252","messageId":"20070723034514.GZ32566@spearce.org","threadId":"9161","inReplyTo":"Pine.LNX.4.64.0707230039560.14781@racer.site","subject":"Re: fast-import and core.autocrlf option","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-23T03:45:14Z","receivedAt":"2007-07-23T03:45:14Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Sun, 22 Jul 2007, Dmitry Kakurin wrote:\n> \n> > It looks to me that CR/LF conversion does not happen during\n> > fast-import even if I have core.autocrlf set to 'input'.\n> > Is this a bug or is there a reason for that?\n> \n> fast-import works on blobs only. So it is expected. Besides, it would \n> slow down fast-import tremendously if you wanted to introduce that \n> behaviour. Therefore I suggest just rolling your own dos2unix instead of \n> trying to play cute games with fast-import.\n\nRight, in fast-import we only process blobs as raw blobs.\nIts rare that we have a file path associated with the blob data\nat the time that we are actually processing the blob itself. E.g.\napplications can send us blobs up front, before they even start to\nsend us commits and path information.\n\nSo if we were to offer the CRLF->LF conversion feature in fast-import\nit would need to be an option supplied at the time the 'data'\ncommand issued, rather than based upon the gitattributes system\nthat is normally used for working tree operations.\n\nIt wouldn't be to difficult to add such an option to the data\ncommand, but I'm not going to be able to get around to it anytime\nsoon. This might be an easy change for someone else to attempt if\nthey were interested in some Git hacking. Should all be isolated\nto the cmd_data() routine in fast-import.c, and just needs to call\ncrlf_to_git() in convert.c, which is uh, static. :-)\n\n-- \nShawn.\n"},{"id":"48255","messageId":"7vwswrojzq.fsf@assigned-by-dhcp.cox.net","threadId":"9161","inReplyTo":"20070723034514.GZ32566@spearce.org","subject":"Re: fast-import and core.autocrlf option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-23T03:51:37Z","receivedAt":"2007-07-23T03:51:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Johannes Schindelin wrote:\n>> On Sun, 22 Jul 2007, Dmitry Kakurin wrote:\n>> \n>> > It looks to me that CR/LF conversion does not happen during\n>> > fast-import even if I have core.autocrlf set to 'input'.\n>> > Is this a bug or is there a reason for that?\n>> \n>> fast-import works on blobs only. So it is expected. Besides, it would \n>> slow down fast-import tremendously if you wanted to introduce that \n>> behaviour. Therefore I suggest just rolling your own dos2unix instead of \n>> trying to play cute games with fast-import.\n>\n> Right, in fast-import we only process blobs as raw blobs.\n> Its rare that we have a file path associated with the blob data\n> at the time that we are actually processing the blob itself. E.g.\n> applications can send us blobs up front, before they even start to\n> send us commits and path information.\n\nDon't the front-ends usually have path information already when\nthey feed you a blob data, especially most of them operate on\nper-file history? If that is the case,...\n\n> So if we were to offer the CRLF->LF conversion feature in fast-import\n> it would need to be an option supplied at the time the 'data'\n> command issued, rather than based upon the gitattributes system\n> that is normally used for working tree operations.\n\n... the \"option\" could be \"this came from such and such path\"\ninstead of \"this is DOS data, please apply crlf\".\n"},{"id":"48258","messageId":"20070723040133.GD32566@spearce.org","threadId":"9161","inReplyTo":"7vwswrojzq.fsf@assigned-by-dhcp.cox.net","subject":"Re: fast-import and core.autocrlf option","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-23T04:01:33Z","receivedAt":"2007-07-23T04:01:33Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> > Right, in fast-import we only process blobs as raw blobs.\n> > Its rare that we have a file path associated with the blob data\n> > at the time that we are actually processing the blob itself. E.g.\n> > applications can send us blobs up front, before they even start to\n> > send us commits and path information.\n> \n> Don't the front-ends usually have path information already when\n> they feed you a blob data, especially most of them operate on\n> per-file history? If that is the case,...\n\nDepends. A frontend can feed huge streams of blobs and use marks\nto make us remember their SHA-1s, then later feed us those marks\nand connect them to paths. Such a frontend may not have exact path\ninformation available when it feeds the blobs to us. Then again\nmaybe it does. Depends on how the source information was organized.\n\n> > So if we were to offer the CRLF->LF conversion feature in fast-import\n> > it would need to be an option supplied at the time the 'data'\n> > command issued, rather than based upon the gitattributes system\n> > that is normally used for working tree operations.\n> \n> ... the \"option\" could be \"this came from such and such path\"\n> instead of \"this is DOS data, please apply crlf\".\n\nHow do we setup .gitattributes? Should it be read from a branch\nin memory, or the working directory?\n\nIf it should be read from a branch, which branch? What if the\nfrontend does not want the .gitattributes file in the history\nof the import? Putting it into a branch just to cause CRLF->LF\ntranslation during import would require filter-branch afterwards\nto strip out the file.\n\nI'd rather make things very explicit. If the frontend wants us to\napply a filter to a data chunk before we work further on it then\nthe frontend should give us the .gitattributes rules to apply as\npart of the data command.\n\n-- \nShawn.\n"}]}