{"thread":{"id":"13058","subject":"git-p4, msysgit, and crlf","startedAt":"2008-04-10T21:53:38Z","lastAt":"2008-04-11T14:34:17Z","messageCount":3,"participants":["Jing Xue","Tor Arvid Lund"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"74101","messageId":"20080410175338.1z2hb82xw4kk4k0o@intranet.digizenstudio.com","threadId":"13058","inReplyTo":null,"subject":"git-p4, msysgit, and crlf","fromName":"Jing Xue","fromEmail":"jingxue@digizenstudio.com","sentAt":"2008-04-10T21:53:38Z","receivedAt":"2008-04-10T21:53:38Z","isPatch":false,"sender":{"key":"jingxue@digizenstudio.com","avatar":null},"body":"\n\nI'm working on a client project, where everything is developed in\nWindows, and perforce is the official SCM. All the files use crlf line\nendings.\n\nI'm trying to use msysgit for my personal SCM, and git-p4 to sync with\nperforce.\n\nThe problem I'm running into is that after\n\n git p4 clone /perforce/path@all proj\n\nall the files in the working directory are converted to lf line endings,\nwhich I'd like to avoid.\n\nI tracked it down to at some point git-p4 executes what essentially\namounts to\n\n p4 -G print /path/to/file#rev\n\nin order to get the content of a revision. When I try to run that\nmanually from the msysgit bash, the file content returned has all\nthe line endings converted to lf.\n\nHowever, if I try to run without \"-G\", i.e.\n\n p4 print /path/to/file#rev\n\nThe content returned has all the original crlf endings left intact.\n\nI know this looks like a p4 issue, but I just wanted to ask other \ngit-p4 users out there whether you have run into this, and how you \ndealt with it.\n\nThanks.\n-- \nJing Xue\n"},{"id":"74119","messageId":"1a6be5fa0804110412v5e11e761xfdf4d4c7d8545661@mail.gmail.com","threadId":"13058","inReplyTo":"20080410175338.1z2hb82xw4kk4k0o@intranet.digizenstudio.com","subject":"Re: git-p4, msysgit, and crlf","fromName":"Tor Arvid Lund","fromEmail":"torarvid@gmail.com","sentAt":"2008-04-11T11:12:46Z","receivedAt":"2008-04-11T11:12:46Z","isPatch":false,"sender":{"key":"torarvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/439758?v=4"},"body":"On Thu, Apr 10, 2008 at 11:53 PM, Jing Xue wrote:\n>\n>\n> I'm working on a client project, where everything is developed in\n> Windows, and perforce is the official SCM. All the files use crlf line\n> endings.\n>\n> I'm trying to use msysgit for my personal SCM, and git-p4 to sync with\n> perforce.\n>\n> The problem I'm running into is that after\n>\n> git p4 clone /perforce/path@all proj\n>\n> all the files in the working directory are converted to lf line endings,\n> which I'd like to avoid.\n>\n> I tracked it down to at some point git-p4 executes what essentially\n> amounts to\n>\n> p4 -G print /path/to/file#rev\n>\n> in order to get the content of a revision. When I try to run that\n> manually from the msysgit bash, the file content returned has all\n> the line endings converted to lf.\n>\n> However, if I try to run without \"-G\", i.e.\n>\n> p4 print /path/to/file#rev\n>\n> The content returned has all the original crlf endings left intact.\n>\n> I know this looks like a p4 issue, but I just wanted to ask other git-p4\n> users out there whether you have run into this, and how you dealt with it.\n\nWell, I'm no expert, but I'll try:\n\nI think if you have the core.autocrlf config option set to true, it\nshould automatically convert line endings to CRLF for you when\nchecking out files to your working dir, and converting it back to LF\nwhen committing. This way, content is always stored with LF only, and\ncan be checked out on any platform using whatever is the \"local\" line\nending by setting this option. This is the default operation in\nPerforce also, as far as I know.\n\nThis git option needs to be set before you do the clone, though. If I\nremember correctly, msysgit sets this as a global option by default\nwhen you install it, but if not (or if you turned it off), you could\nprobably try:\n\ngit init\ngit config core.autocrlf true\ngit p4 sync /perforce/path@all\n\ninstead of your git p4 clone\n\nYou can verify that it is set by:\ncd /path/to/git-cloned/p4-repos\ngit config --list\n\n... and looking for core.autocrlf=true\n\nBest of luck.\n-Tor Arvid-\n"},{"id":"74123","messageId":"20080411103417.xbu855kqasgw80gc@intranet.digizenstudio.com","threadId":"13058","inReplyTo":"1a6be5fa0804110412v5e11e761xfdf4d4c7d8545661@mail.gmail.com","subject":"Re: git-p4, msysgit, and crlf","fromName":"Jing Xue","fromEmail":"jingxue@digizenstudio.com","sentAt":"2008-04-11T14:34:17Z","receivedAt":"2008-04-11T14:34:17Z","isPatch":false,"sender":{"key":"jingxue@digizenstudio.com","avatar":null},"body":"\n\nQuoting Tor Arvid Lund :\n\n> Well, I'm no expert, but I'll try:\n\nThanks. :-)\n\n> I think if you have the core.autocrlf config option set to true, it\n> should automatically convert line endings to CRLF for you when\n> checking out files to your working dir, and converting it back to LF\n> when committing. [snipped]\n\nI did try exactly that - actually I tried explicitly setting it either \nway, and neither worked. At any rate, the files in my case _have_ \nCRLF in perforce, and what I want to achieve is really just to have \neverybody leave them alone, i.e., no conversions whatsoever. :-)\n\n From my code reading, core.autocrlf doesn't seem to be referenced \nanywhere in git-p4 anyways. In fact, besides the p4 -G issue I \ndescribed in my first post, git-p4 itself also seems to always convert \n\"\\r\\n\" to \"\\n\" on any Windows text files (in method P4Sync.commit()), \nprior to send them to git-fast-import.\n\nAnd git-fast-import doesn't really do any conversion. The commit data \nit receives is always treated as binary (which is good). So it seems \nto me that the core git is off the hook here.\n\nCheers.\n-- \nJing Xue\n"}]}