I have have to work on a windows machine at work but have a mac at home. All of my rails code is written on the mac which is using RVM and deploying to heroku using GIT.
However I want to start working on the code on a windows machine (code held in dropbox and synced automatically)
I remember that line endings caused hell in git when I used to write python code... What are the requirements to be able to right RoR using two different operating systems?
You can configure git to convert line endings to one or the other upon committing: http://help.github.com/line-endings/
When you are describing paths, be sure to use built in methods for constructing them OS independently, like File.join.
You need to use the core.autocrlf feature.
From the manual
core.autocrlf
Setting this variable to "true" is almost the same as setting the text attribute to "auto" on all files except that text files are
not guaranteed to be normalized: files that contain CRLF in the
repository will not be touched. Use this setting if you want to have
CRLF line endings in your working directory even though the repository
does not have normalized line endings. This variable can be set to
input, in which case no output conversion is performed.
git config --global core.autocrlf true
So, In your windows machine, set this feature to true, which means,
During commit, your line endings will automatically be changed to LF and when you checkout your local files will have Windows' line endings (i.e., CRLF)
git config --global core.autocrlf input
In your non-Windows machine, set this to input, which means
Don't do any conversions, I'm not prone to any line ending changes
Why not configure heroku on your work machine instead? You already have version control (git) to take care of syncing and sharing your app.
Related
I'm currently developing for a Ruby on Rails application. I am on a windows machine, using ubuntu through WSL. We have rubocop setup to track formatting on git pushes, and I always run into the same issue. When adding this comment to the top of any file, I receive the error Layout/EndOfLine: Carriage return character detected. The issue seems to be talked about here as well Layout/EndOfLine: Carriage return character detected. module TieConnector
# frozen_string_literal: true
The solution here seems to be to disable the warning, or manually convert the files before pushing.
Does anyone know if there is another solution here? I don't believe I can edit the rubocop settings as it is not my project. The converting method does work, but gets a bit tedious to do every time I make a new pull request.
Would there be a way to run the dox2unix convert when running git push while targeting the files staged for commit? Or a way to force my machine to use the unix encoding by default?
Any help is appreciated, thank you
It's a common issue on windows. If you are using vscode you can convert all your files to LF with this shortcut: ctrl + shift + P => 'change all end of line sequence' => Enter => Enter => Enter => 'LF' => Enter Then you can commit and push your code. If it still don't work you might see your git configuration, autocrlf in particular. See this response: stackoverflow.com/a/20653073/7542830
To solve it on a repository level:
git config --local core.autocrlf input (on you project root)
I'm using RubyInstaller2 (MSYS2 backend, not WSL) and ran into the same issue when RuboCop made some fixes (apparently is used CRLF instead of LF).
I fixed all the files in vim with :bufdo %s/\r//, but still got the error as the first character was still a CR (or CRLF).
Had to end up using dos2unix, as recommended in Layout/EndOfLine: Carriage return character detected. module TieConnector
[EDIT]: Error is intermittent on Windows due to missing BOM: https://github.com/rubocop/rubocop/issues/4669
I don't understand what is the need/use of the git unpack-objects command.
If I have a pack file outside of my repository and run the git unpack-objects on it the pack file will be "decompressed" and all the object files will be placed in .git/objects. But what is the need for this? If I just place the pack and index files in .git/objects I can still see all the commits and have a functional repo and have less space occupied by my .git since the pack file is compact.
So why would anyone need to run this command?
Pack file uses the format that is used with normal transfer over the network. So, I can think of two main reasons to use the manual command instead of network:
having a similar update workflow in an environment without network configuration between the machines or where that cannot be used for other reasons
debugging/inspecting the contents of the transfer
For 1), you could just use a disk or any kind of mobile media for your files. It could be encrypted, for instance.
I am learning Ruby on Rails and I use Windows 7. When I try to commit my changes to Git, I receive the fatal: LF would be replaced by CRLF message.
It seems that rails generate generates files with LF, not CRLF. Of course, I may switch from
git config --global core.autocrlf true
git config --global core.safecrlf true
to
git config --global core.autocrlf true
git config --global core.safecrlf warn
but I don't like the possibility of crushing any committed binary into pieces.
I tried to avoid the problem with .gitattributes, but my lines like
* text=auto
*.rb text
do not help.
Is there a way to make Rails generate files with CRLF ending? Or is there a way to make Git auto-transform the .rb and .erb files, but not others?
I don't like the possibility of crushing any committed binary into
pieces.
Are you sure that's a real problem?
If you turn the warnings off (core.autocrlf true) git will make the adjustments when you commit and you can continue being productive.
If you truly have a solid reason for not wanting to do this you are going to have difficulty as I don't think there is a simple way (there is always some way) to have Rails generate files with the CRLF ending and it's weird to have git auto-transform based on file type.
I can certainly be wrong, but it seems like you're trying a bit too much to work against your tools?
Possibly useful reference: git commit creates assets and temporary files for some reason
If you really want to go down the road of attempting to configure git to make these changes you can check out a git attribute filter driver as suggested in this response: Can git automatically switch between spaces and tabs?
Another useful reference to the above proposed solution: https://stackoverflow.com/a/2354278/1026898
I am using Gerrit for code review for all the SQL files that is being used in the Project. Gerrit is hosted on Linux machine and its version is 2.6.1.
I have problem in comparing SQL patch set and all the SQL files are considered to a binary file by Gerrit and hence unable to provide the comparison.
For reference, following is the response on Gerrit comparison:
diff --git a/web/dev-db/sp/dbo.usp_getactivityownerlist.sql b/web/dev-db/sp/dbo.usp_getactivityownerlist.sql
index f623dd3..e2ed93b 100644
--- a/web/dev-db/sp/dbo.usp_getactivityownerlist.sql
+++ b/web/dev-db/sp/dbo.usp_getactivityownerlist.sql
Binary files differ
Is there any way I can configure Gerrit to consider .SQL file as a text file rather than binary file so that patch comparison is easy.
Try adding the following line to your $repo/.git/info/attributes:
*.sql crlf diff
It normally happens when user set core.autocrlf to false in global config file. This effectively disabled "smart" detection of line endings in text files.
It can be encoding issue as well, Git works best with utf-8, if the encoding is in something like utf-16, Git will think it's binary, no matter what you set in .gitattributes
I'm trying configure PyScripter 2.5.3 to use a version of Python that is installed in a non-standard install location (i.e., c:\MyProj\Python27).
NOTE: I also have ActivePython 26 and 27 also installed, in the default locations c:\python26 and c:\python27)
I have a short program that simply dumps the python path to verify that I have the correct version:
import sys; print( "\n".join(sys.path) )
When I'm using the "desired version", I'll see "c:\MyProj\Python27\lib" show up on the path.
I've looked at several postings (one is How to change the version of python that pyscripter uses) and most just say the defaults work and the defaults do work. I'm trying to use a non-default directory.
I've used Tools | Configure Tools to set the Python Interpreter, and Command Prompt to run "MyProj" version of python.
So Tools | Python Interpreter, starts c:\MyProj\Python27\python.exe
Also Tools | Command Prompt, starts c:\MyProj\Python27\python.exe version.
But I can't get the Python IDE to use the desired version when I use "Run | Debug (F9)".
I've configured Tools | Options | IDE Options | Python engine type = peRemote.
I've also tried internal.
I've tried starting PyScripter from the command line with the following options (none of these examples worked)
...\PyScripter.exe --python27 --pythondllpath=C:\MyProj\Python27
...\PyScripter.exe --python27 --pythondllpath=C:\MyProj\Python27\python27.dll
...\PyScripter.exe --python27 --pythondllpath C:\MyProj\Python27
...\PyScripter.exe --python27 --pythondllpath C:\MyProj\Python27\python27.dll
I've tried having only my version of python on the windows PATH (removing c:\Python27)
set PATH=C:\MyProj\Python27;%PATH%
...\PyScripter.exe
This has also failed to work.
Has anyone had success at using a non-standard location? If so what steps were followed?
I don't know if this is the best way to do it, but those are the two ways I did it:
WAY 1 (The best of two)
Go to PyScripter>>Tools>>Options...>>Custom Parameters... and add the following values
1. PythonDir = C:\Program Files\CustomPythonInstallation
2. PythonExe = C:\Program Files\CustomPythonInstallation\python.exe
3. PythonVer = 3.3.3
Note: Adapt the Name = Value pairs above to your case.
And close the window with OK button.
Now select PyScripter>>Run>>Python Engine>>Remote and your are ready to go.
WAY 2 (The more temporary solution)
Go to PyScripter>>Run>>Configure External Run...
set the "Application:" field to your python.exe file
Close the window with OK button.
Make sure you run your scripts with PyScripter>>Run>>External Run (Alt+F9)
I hope this helped, good luck.
I'm using two different pythons, tried to use pyscripter with both, but it kept messing up. My simple solution was to download the standalone pyscripter that doesn't use the registry, put copies into two different directories, then set each up for the different py. You can then right click on their icons and set them to start in the proper directories. You can also make two cmd icons and set them respectively so you have a command line. The command line icon can also be set to start in your working directory, although that's normally one level below python, and if it isn't on the path, you have to type ../python to get it (or use a keyboard macro for that.) This works trouble free.
I did delete both pythons and removed them from the system path just in case pyscripter looked for them. Then I installed 2.7 and set up the first scripter. I installed 34 and set up the second. Oddly, the scripters found the correct py each time - I imagine they go for the highest one. But you can also set that in scripter options. And frankly, it may not be necessary to delete py**. If not deleting them doesn't work you can just make a fresh copy of scripter and try again, since that will be a new standalone. For all I know you can reinstall python on the path once pyscripter is set up for each. I haven't tried that. Fiddle around. You can always make a new copy of the pyscripter standalone directory if things don't work out ;')
The interactions between the registry, the path, and the installed pyscripter just led to too many headaches.
Oh, pyscripter doesn't seem to play well with 3.4 but there's a fixed exe for your 3.4 standalone, here - just replace the 3.4 standalone python.exe with this one:
https://pyscripter.googlecode.com/issues/attachment?aid=7680027000&name=PyScripter-Updated.7z&token=ABZ6GAd40xS88r5vwgY9m8Y18vSFKN8q3g%3A1421517339924