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.
Related
Hi I am trying to update one of my remote repositories. When I use commit in git bash it shows that a SWP file already exists and askes me if I want to (R)ead only the file (E)dit (D)elete. I tried editing the file, but I cannot save the changes and therefore cannot commit my changes. Any idea what is going on.
EDIT:
It's working now thanks to those that helped. In terms of the question I will try to only show the relevant information when asking questions in the future.
When you edit a file, Vim stores your changes in a "swap file" so that you can recover your work if Vim's process is killed before you could save. This can be caused by something as problematic as a system crash or, simply, by closing your terminal window while Vim is running.
If Vim is quitted "normally", it deletes the swap file it created.
If it is not, the swap file is left behind and, the next time you open the same file, Vim will notice the presence of the swap file and offer you the possibility to recover the work that you "lost" the last time Vim quitted "abnormally".
That is the interactive screen you get with the "(R)ead only the file (E)dit (D)elete" prompt.
Now, when you are starting out with stuff like Git, Vim, the command line, etc. it may happen quite often that you find yourself in an uncomfortable situation, not knowing exactly what to do to fix it. This is frankly quite normal at this stage. In those situations, closing the terminal window might seem like a good first step in going back to a more comfortable situation to start again. In some cases, however, doing so might leave a trail of hidden files and broken states that might make it harder than you hoped to get to that comfortable situation.
When you do $ git commit, Git populates a specific temporary file located in your local .git directory:
.git/COMMIT_EDITMSG
with some text describing the commit you are about to make, and opens that file with your designated editor, which is the dreaded Vim by default.
When you start editing the file, Vim creates a swap file. If you insert your commit message, write the file, and quit Vim normally, the swap file is deleted and you won't ever be prompted about it. If you close the terminal window before writing the file, the swap file stays behind and Vim will prompt you about it the next time you try to make a commit.
From there you have quite a few options…
Go into your .git directory and delete the swap file(s) manually. They should be named .git/.COMMIT_EDITMSG.swp (or .swo, .swn, etc. see :help swap-files in Vim). This should give you a clean state for the next time you do $ git commit.
Don't close your terminal window when faced with a problem. Instead, try to analyze what went wrong and look for proper ways to fix it. If you have to close the terminal window, look for stray swap files just in case.
Learn Vim's basics so that you don't have to close the terminal window when you mess up your commits. Try $ vimtutor.
Tell Git to use a text editor you are more familiar with. Search Stack Overflow, I am sure there are dozens of Q/As about that.
Configure Vim to never create swap files. You can do it in Vim's configuration file:
# in $HOME/.vimrc
set noswapfile
This won't tell it to ignore existing swap files, though, so you might want to delete them manually anyway.
Use a graphical Git client instead of the CLI.
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.
When I edit any .coffee file in my mvim and try to save that file with any line longer than 80 symbols, I get such error.
file_name.coffee |18 error| Line exceeds maximum allowed length Length is 91, max is 80.
This is extremely annoying, especially taking into consideration that we have convention of max 100 symbols per line in our company and even code of other team members causes problems for me locally.
The only place where I can change this limit is in nodejs module in file .../node_modules/coffeelint/lib/coffeelint.js, which has such line:
max_line_length: {
value: 80,
-level: ERROR,
+level: IGNORE,
message: 'Line exceeds maximum allowed length'
},
But, of course, editing sources of nodejs libraries is not a good option.
In my mvim I use these dotfiles - https://github.com/skwp/dotfiles
In my project directory I have .coffeelint.json, but it does not work, however, it seems to contain needed and valid code for that (it works perfectly on TravisCI and on machines of other team members).
Questions:
Is there any place where I can turn off coffeelint call when saving file?
Is there any place where I can configure my coffelint max allowed line length?
Update:
Putting properly named (.coffeelint.json) config file into home directory helps, but is not proper solution in my case.
It seems it is more a coffeelint question than a Vim question.
From http://www.coffeelint.org/#options :
It seems you have to generate a configuration file, tweaking the following option.
max_line_length This rule imposes a maximum line length on your code.
Python's style guide does a good job explaining why you might want to
limit the length of your lines, though this is a matter of taste.
Lines can be no longer than eighty characters by default.
default level: error
It also seems you have to call coffeelint with your configuration file:
From : http://www.coffeelint.org/#usage
coffeelint -f coffeelint.json application.coffee
You probably have to find in your dotfile where the coffeelint invocation is done, and add the configuration file with the -f option there.
You don't have to pass the config file explicitly. Here are the user docs for CoffeeLint. You should either create a ~/coffeelint.json file or create a coffeelint.json in the root of your project.
In all project parts (5 different repos now) we currently have .coffeelint.json file, that is not the proper name for coffeelint, if you want it to pick config file automatically. Current .coffeelint.json is used on TravisCI when checking code and is invoked with -f option, as it turned out. So I my case I have two ways to fix weird behaviour (that is intended behaviour, actually):
Copy one of the configs from 5 related repos to ~/coffeelint.json, so that coffeelint will use it automatically when vim will check file on save (but this will not do if some repos will have different configs, however, this solution does not require any changes to repos).
Create copy of each config file in each repository (so I'll have both .coffeelint.json and coffeelint.json in each repo) and add the newly added one to .gitignore, so that team members will not see it in their editors. This option is also inappropriate and looks ugly, cause I have to add 5 changes and 5 commits.
It seems that guys from the team decided to name coffeelint config file not properly in order to hide it visually in code editors. Solution cost me nerves, so, probably, I'll reconfigure everything properly and will rename configs to default names.
It would be nice if coffeelint supported multiple config files with levels of priority, but this is not possible now.
Git Extensions has repeatedly added four javascript files to my commit. I have never knowingly edited these files and the diff for these files is blank. So I don't know what, if anything, is being changed.
If I select the reset option for the files, they are removed from the commit list for a while. They eventually come back, but I have yet to notice a pattern or a particular action that triggers their return.
What is likely to be causing this and what can I do to fix it?
The files are:
knockout-2.1.0.debug.js
knockout-2.1.0.js
jquery.unobtrusive-ajax.min.js
jquery.validate.unobtrusive.min.js
This was a line ending issue. There was a difference in the settings for how to handle line endings between myself and my coworkers. Correcting this difference fixed the problem.
The command git diff --ignore-space-at-eol can be used to check for any differences that are not caused by end of line spaces.
Credit goes to #SamHolder for pointing me in the right direction and providing the above command.
I have set vim as the svn editor.
Now, whenever I do 'svn ci', it opens up vim editor allowing me to enter the commit comments.
Below the comment section, there are set files which will be checked in. So, If I don't want certain files to be committed, I remove it from the list of files in the vim editor. But when I save and quit the vim editor, svn still checks-in the file I have removed in the editor.
Is this expected behavior? Or I need to set something in the svn configuration to make it work?
That list of files in the comments section is... well... just comments. It doesn't really do anything - it's just there to help you by letting you see what you are committing.
If you want to not commit certain files, you have to do it beforehand:
You can specify the files you want commit in the svn commit command instead of committing everything.
You can add the ignored files to your svn:ignore property.
You can use some GUI tool that'll let you visually select what to commit and what not.
There is some trick with changelists. Haven't tested it(I don't use SVN since it's crap), just found it in this answer when I googled.
Use Git with git-svn, and simply git reset HEAD the files you don't want to commit to unstage them.
The list in the editor is just informative; it tells you what will be committed but does not influence what will actually be committed (the relationship is the other way round). If that's not what you wanted, you have to kill the svn ci (typically by doing Ctrl+Z and then issuing the kill at the command line). To change what is committed, you need to list the files explicitly to svn ci; it only defaults to all known, modified files (i.e., those listed when you run svn status).
If the above way of working isn't to your taste, you might be better off getting one of the many GUIs that wrap around SVN. They almost universally make interactively selecting what to commit easier.