threads / discuss / 13058

git-p4, msysgit, and crlf

Subject: git-p4, msysgit, and crlf

## tl;dr

3 messages between Apr 10, 2008 and Apr 11, 2008.

replies: 2people: 2as markdown or json

Jing Xue· Apr 10, 2008, 21:53 UTC · lore

I'm working on a client project, where everything is developed in Windows, and perforce is the official SCM. All the files use crlf line endings.

I'm trying to use msysgit for my personal SCM, and git-p4 to sync with perforce.

The problem I'm running into is that after
   git p4 clone /perforce/path@all proj

all the files in the working directory are converted to lf line endings, which I'd like to avoid.

I tracked it down to at some point git-p4 executes what essentially amounts to

   p4 -G print /path/to/file#rev

in order to get the content of a revision. When I try to run that manually from the msysgit bash, the file content returned has all the line endings converted to lf.

However, if I try to run without "-G", i.e.
   p4 print /path/to/file#rev
The content returned has all the original crlf endings left intact.

I know this looks like a p4 issue, but I just wanted to ask other git-p4 users out there whether you have run into this, and how you dealt with it.

Thanks.
-- 
Jing Xue
Tor Arvid Lund· Apr 11, 2008, 11:12 UTC · re: Jing Xue · lore

Re: git-p4, msysgit, and crlf

On Thu, Apr 10, 2008 at 11:53 PM, Jing Xue <jingxue@digizenstudio.com> wrote:
Show 33 quoted lines
>
>
>  I'm working on a client project, where everything is developed in
>  Windows, and perforce is the official SCM. All the files use crlf line
>  endings.
>
>  I'm trying to use msysgit for my personal SCM, and git-p4 to sync with
>  perforce.
>
>  The problem I'm running into is that after
>
>   git p4 clone /perforce/path@all proj
>
>  all the files in the working directory are converted to lf line endings,
>  which I'd like to avoid.
>
>  I tracked it down to at some point git-p4 executes what essentially
>  amounts to
>
>   p4 -G print /path/to/file#rev
>
>  in order to get the content of a revision. When I try to run that
>  manually from the msysgit bash, the file content returned has all
>  the line endings converted to lf.
>
>  However, if I try to run without "-G", i.e.
>
>   p4 print /path/to/file#rev
>
>  The content returned has all the original crlf endings left intact.
>
>  I know this looks like a p4 issue, but I just wanted to ask other git-p4
> users out there whether you have run into this, and how you dealt with it.
Well, I'm no expert, but I'll try:

I think if you have the core.autocrlf config option set to true, it should automatically convert line endings to CRLF for you when checking out files to your working dir, and converting it back to LF when committing. This way, content is always stored with LF only, and can be checked out on any platform using whatever is the "local" line ending by setting this option. This is the default operation in Perforce also, as far as I know.

This git option needs to be set before you do the clone, though. If I remember correctly, msysgit sets this as a global option by default when you install it, but if not (or if you turned it off), you could probably try:

git init git config core.autocrlf true git p4 sync /perforce/path@all

instead of your git p4 clone

You can verify that it is set by: cd /path/to/git-cloned/p4-repos git config --list

... and looking for core.autocrlf=true

Best of luck. -Tor Arvid-

Jing Xue· Apr 11, 2008, 14:34 UTC · re: Tor Arvid Lund · lore

Re: git-p4, msysgit, and crlf

Quoting Tor Arvid Lund <torarvid@gmail.com>:
> Well, I'm no expert, but I'll try:
Thanks. :-)
> I think if you have the core.autocrlf config option set to true, it
> should automatically convert line endings to CRLF for you when
> checking out files to your working dir, and converting it back to LF
> when committing. [snipped]

I did try exactly that - actually I tried explicitly setting it either way, and neither worked. At any rate, the files in my case _have_ CRLF in perforce, and what I want to achieve is really just to have everybody leave them alone, i.e., no conversions whatsoever. :-)

 From my code reading, core.autocrlf doesn't seem to be referenced  
anywhere in git-p4 anyways. In fact, besides the p4 -G issue I  
described in my first post, git-p4 itself also seems to always convert  
"\r\n" to "\n" on any Windows text files (in method P4Sync.commit()),  
prior to send them to git-fast-import.

And git-fast-import doesn't really do any conversion. The commit data it receives is always treated as binary (which is good). So it seems to me that the core git is off the hook here.

Cheers.
-- 
Jing Xue

← back to recent threads