I had a project on Mac and uploaded it to a perforce server. When I got the project from PC all the line endings were changed and now it does not compile on PC. Is there a way to automatically change the line endings like they were before or I must submit again all the project from Windows? Is there any way to make perforce to keep my files AS THEY ARE? I really don't want to have stupid modifications in my source files.
Thanks!
EDIT:
It has to do with perforce, I just edited 10-20 files on MAC to make a multiplatform project to compile. The rest of 140k files were not changed and not even opened on Mac(they were opened by compiler to compile them:P). If I copy the project on PC the line endings are ok.
Line endings for text files are controlled by your client spec setting. You need to make sure that your client's 'LineEnd' value is set properly. In general, this should be left to 'local' which should do the right thing for whatever operating system you are using.
That said, depending on how this value was set on your Mac when you originally uploaded the files, I suppose that there could possibly be some problem when syncing those files to your PC.
I would check to make sure that LineEnd is set to 'local' for your clients. There is a note on the Perforce Knowledge Base site here that talks more in depth about proper settings for Macintosh clients. That might be a place to start as well to make sure that you have things properly configured on your Macintosh.
Yes you can. Using Unix line-endings for both your clients will tell the perforce clients to leave the files unchanged from how they were submitted. You can also setup a trigger on the server to force it this way, refer to my answer to this question:
Setting Perforce line endings
This doesn't have anything to do with perforce really, although it does handle the problem.
http://kb.perforce.com/article/63
Line endings on UNIX, PC and Mac machines are all different. This is what your seeing. Transferring the same file between PC and Mac over any medium would have the same results. You can probably set your editor on the Mac to save the file with windows line endings if you want to get around this another way.
I was wrong "Perforce processes all text files using Unix-style LF line-endings". I'd check p4 client LineEnd value (should be local on both machines I think) and ensure you're using a version of p4 >= 2001.1
Related
I have read so much about the config setting core.autocrlf and what you can set it to. Yet I am having a lot of problem understanding why it doesn't work the way I expected it to.
Machine I'm working on: Windows
Experience with git: Beginner
Terminal: git bash
core.autocrlf: true
So let's begin with the first bit of confusion. I used the command echo hello > file1.txt in my working directory, then I also created a text file by opening notepad and saving it in the same location as my "file1.txt" and giving it the name "file_windows.txt". When opening both files on notepad, I saw a difference, "file1.txt" had "Unix (LF)" marked at the bottom of the notepad tab, whereas "file_windows.txt" had "Windows (CRLF)". I imagine the distinction was made since the first file was made with a unix/linux command in comparison to the other file which was created through the use of notepad and windows.
Now the problem arises when I tried adding those files to the staging area. When using the command git add file1.txt, I was faced with the following message:
warning: LF will be replaced by CRLF in file1.txt.
The file will have its original line endings in your working directory
I was a bit shocked since I thought that having core.autocrlf set to true would mean that git would make changes to the file by making sure "crlf" was replaced with "lf" when adding to the staging area, not the other way round suggested by the warning, of course the point of having that setting on was so that if let's say for example, someone on a linux platform with core.autocrlf set to false, would be able use that git repository without having to worry about some file having "crlf" instead of "lf".
Then when using the command git add file_windows.txt there would be no warnings as expected, since I imagine it is doing what it is supposed to do and replace "crlf" with "lf" when adding it to the staging area. What I am trying to get at here is that if there was for some reason to be a file that I'm working with that is in "lf", I wouldn't want it then switching it to "crlf" when I am adding it to the staging area, since there really wouldn't be a need to do so and it would probably not be beneficial.
Another thing to mention is that (although shouldn't be taken too seriously since I am a beginner using git so I don't know if it is because I am doing something wrong) when I commit both files, then use the command git checkout <commit hash> and then go open the files by start file1.txt (which opens them up on a notepad), I don't end up seeing the change which the warning stated it would make, it still shows as "Unix (LF)" and not "crlf" so it leaves me even the more confused.
Coudl someone explain what is going on please?
The warning "LF will be replaced by CRLF in file1.txt" means that it will be replaced by CRLF when you check the file out next. The file is indeed stored with LF endings in the repository, since all files subject to text handling are stored that way.
However, when you use git checkout, Git doesn't check out files which are up to date in the index. That's why you don't see git checkout modifying the files in the working tree.
This message is ultimately harmless, but it just warns you that you've placed a file into the working tree that does not use the line endings that you've requested, explicitly or implicitly, which means you may end up with different behavior next time you clone or checkout the repository. If all your tools handle any line ending gracefully, or you've properly configured your .gitattributes file to specify appropriate line endings, then you shouldn't have anything to worry about.
I have noticed that some .Net code committed by a new contracting team has strange line endings. When I do a hex dump of the files I see that each line ends with 2 carriage returns (0d) and 1 line feed (0a).
When viewed in Visual Studio it looks like every code line has an empty line after it, which looks very odd.
What can cause this? It it some strange IDE? Could it be caused by Perforce? (I got the code out by syncing a Perforce workspace).
The only time I've ever seen non-standard line endings before is when people copy/paste code from a web page, email, or chat window. Could that be the cause?
If they submitted Windows-style (CRLF) line endings but used the unix (LF) LineEnd setting in their client workspaces, then the files would have an extra CR as part of each line, and a Windows machine would sync them down as CRCRLF. That's the most likely explanation for what you're seeing.
The ideal way to fix this is just for everyone to use a LineEnd that matches their environment (usually the default of local works just fine for this), but if someone needs to use a mix of tools/platforms within a single workspace, switching to the share LineEnd option will force everything to be normalized on submit by stripping all the CRs. (This also makes it impossible to submit text files with actual CR characters, but that's usually not a big deal -- for files where you don't want any sort of transformation to occur, use the binary filetype.)
I'm on a Windows machine, and in my P4V workspace:advanced-settings, I have the following selected:
But I still notice extra spaces in some of my files after submitting and checking on a different machine. Is there a way to force every checkout and submission to be Unix style?
Note, I can't modify server settings, only my local workspaces.
If you set the LineEnd to unix and the files you sync have \r characters in them, it means that somebody using unix submitted them in that form (i.e. the files were checked in with the understanding that the Unix version of them is supposed to have those characters in there distinct from the native line endings). If you submit Windows-style files from a unix-mode workspace, you're saying that all unix workspaces should have Windows-style line endings for those files. This is desirable in some instances, like when you're using Unix machines to build packages for Windows systems, but for source code that's meant to be used cross-platform it's generally a bad thing.
It's not too hard to go through the history, figure out who did that, and cluebat them (or get the admin to force a fix of their LineEnd setting so that it actually matches the contents of their workspace), and I wholeheartedly recommend doing this any time you ask for unix files and get a win-style file that you didn't want. Usually if everyone uses the default setting of local everything works fine.
As far as fixing the files, a pretty easy method is to change your LineEnd to share, open all the files for edit, and then submit them -- the share setting forces all the \r characters to be stripped out on submit, as if you were running dos2unix over all your files every time you submitted.
I am working on Windows 7 and have a node.js project which is under git. I set up my TortoiseGit to autocrlf: false and safecrlf: false. Then changed all project files' line endings to LF. The project starts and operates normally and I see no reason to go back to CRLF.
Should I expect any side effects after doing this?
No, there is no problem at all using *nix end of line sequences on Windows (LF instead of CRLF). In fact, my personal recommendation would be to ensure your Windows editor (if you're developing node.js on Windows) to use LF.
Just as an example, I use Visual Studio Code for my editor developing node.js, and I have specified the following in my user settings to use LF instead of CRLF: "files.eol": "\n". Now I no longer need to worry about that.
CRLF line endings cause breaking issues in a node.js application that is run on Linux, and it isn't the most straightforward thing to troubleshoot if you don't know what to look for.
TL;DR Use LF while developing node.js applications on Windows if you really care about cross-platform (which you should care).
Note: just because git changes your line endings doesn't mean that is the solution. Even if you are ok with your version control changing your source code (which I don't recommend), if you do an npm publish it'll be using your source files locally and you could sneak CRLFs into the npm registry.
If all tools/editors/IDEs are LF compatible, then there is no problem.
Otherwiese you might get errors or mixed line endings on saving.
In order to make sure no conversion is happening for other users who clone your repository you can put a .gitattributes file into the root folder containing: * -crlf which disables all crlf conversions.
Is there a way to tell Perforce to leave text files alone without setting the file-type as binary? Or barring that, is there a way to tell the Perforce client to diff binaries? Binary usually isn't desirable, because I lose the ability to diff.
To clarify: If I edit and make changes to a *.txt file on my window client, newlines will have CR+LF as per the DOS format. But if I P4 sync on a Unix client, it will have LF only. I need Perforce to keep the format as-is, regardless of where the Perforce client lives.
That said, I do have a work-around: Set file-type as binary; and/or create a branch with text files set as "text", and integrate periodically back into the mainline where text files are set as "binary". But this is an overly-complicated work-around for what should be a very simple problem.
Finally, I'm on Perforce Windows client 2006.2.
Thanks in advance.
Set all of your client/workspace specs to 'unix' line-endings. Then no conversion will take place when you check in on Windows.
See http://answers.perforce.com/articles/KB_Article/CR-LF-Issues-and-Text-Line-endings/
The Perforce client can handle line ending properly when syncing to different platforms provided you have LineEnd option set properly on your client. Perhaps you have yours set wrong? Open up your client specs and set the LineEnd option according to your needs.
Check out this KB article on their website for more info. Here's an excerpt:
On the server side, Perforce processes
all text files using Unix-style LF
line-endings. Although Perforce stores
server archive files on disk in the
operating system's native line
termination convention (CR/LF on
Windows, LF on Unix), all line-endings
are normalized to Unix-style LF
line-endings for internal Perforce
Server operations such as p4 sync, p4
submit and p4 diff.
On the client workspace side, Perforce
handling of line-endings is determined
by a global option for each
clientspec. When you sync text files
to a client workspace with p4 sync, or
submit them back to a Perforce Server
with p4 submit, their line-endings are
converted as specified in the
clientspec LineEnd section.
When adding text files that you want to be considered binary to Perforce, use the command p4 add with the -t option to override the type mapping table. See the documentation here. The example given there is p4 add -t binary file.pdf.
I have just come across exactly the same problem, but have a better solution that does not involve changing client specs (which are international, and not all of which I have write access to).
All of our clients are Windows PCs, but Cygwin is included within the Perforce Depot. Cygwin is a Windows implementation of Unix, and requires that text files use LF for line endings.
A possible solution for older versions of Cygwin is to mount the root using the "text" option, meaning that files can have CR+LF line endings. However, on upgrading to Cygwin 1.7.9, this no longer worked, as mounts are transient unless they are written into /etc/fstab. I did not manage to make this work.
Luckily, the Perforce Guru sitting next to me came up with the solution of changing the filetype to binary+D, which uses the same RCS incremental patch storage as text files, but without the automatic line ending conversion.
I can diff these "text" files successfully between my local workspace and the depot.
Give the files a different extension.