I and a colleague of mine work in Eclipse on Windows machines.
When I push my changes to Gerrit, there are \r marks in the source view.
When my colleague does the same, there are no such characters.
The git settings on both machines are equal to:
$ git config --global --get core.eol
native
$ git config --global --get core.autocrlf
false
$ git config --global --get core.whitespace
I'm using following Eclipse settings.
I tried to run File -> Convert line delimiters to -> Windows, but it didn't help (git status didn't show any modified files after I did this).
How can I make sure that when I commit my changes, there are no \r characters in Gerrit?
The \r is because windows line endings are \r\n (vs. unix line endings which are just \n) You could switch to unix line endings but you would have to commit all the files.
Gerrit has an option to hide line endings, it's under preferences when you're in the source view. This seems like the best option.
Related
IDE : Eclipse & VS code
Git tool : source tree, VS code
Action : Nothing changed in my code. But when pressing ctrl+s, it's able to save and suorceTree will show every line has been edited. The only change I found (show by sourceTree) :
form:
import org.apache.poi.ss.usermodel.Cell;␍import org.apache.poi.ss.usermodel.CellType;
to this:
import org.apache.poi.ss.usermodel.Cell; import org.apache.poi.ss.usermodel.CellType;
I'm quite sure that I'm not using any "format code on save" settings, is it a git bug in this version?
trying : ctrl + s in vs code, eclipse, wordPad
excepting : to edit a line (not changing the whold file when saving) and push to git branch.
By default Git uses LF (Linux) Line Endings, Windows on the other hand pushes CRLF Line Endings.
Git tries makes the assumption that if you are using Windows, you want CRLF, this is good for normal users because programs generally come pre-configured to use CRLF.
If you are using Windows and you are getting false changes reports, it is likely that Git is ignoring the line endings, so when you clone or pull code, it will be in LF. Then when you save your progress in your CRLF-configured editors, each line ending is being changed back to CRLF, modifying the whole file.
This behavior can be altered during the Windows installation of Git, pay close attention to it next time you install Git.
Solution 1: Configure Git
You can configure Git to *replace LF to CRLF when checking out (cloning, pulling...) so you can work in CRLF, and then replace CRLF back to LF when you commit so that you don't commit whole practically unchanged files. The option you want is core.autocrlf, you can do it in your terminal:
git config --global core.autocrlf true
The --global parameter makes this change for your entire user (which you probably want to)
Solution 2: Start using LF
You could configure your Text Editors and IDEs to use LF by default, that way when you clone or pull in LF, you will keep working and saving your work using LF, retaining Git's default line endings.
You can usually find this option refeered to as EOL (End Of Line).
Because of the changes in line endings, commits looks a lot bigger than they should be.
I have egit 4.6.1.201703071140
Before using egit, the command
git ls-files --eol
shows
i/mixed w/mixed attr/ somefile
then, after commit in Eclipse via git staging view, it is:
i/lf w/mixed attr/ somefile
Another example:
i/crlf w/crlf attr/ somefile2
becomes:
i/lf w/crlf attr/ somefile2
You can see egit is changing the first column to i/lf.
In GitHub you can use ?w=1 to dampen the noise, but how do I fix the problem itself?
git config
core.autocrlf=input
core.repositoryformatversion=0
core.filemode=true
core.logallrefupdates=true
remote.origin.url=https://github.com/plutext/docx4j.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
branch.master.rebase=false
According to https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration:
You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input.
You probably want to use false instead.
I'm transfer a hg repo from a Windows environment to Unix. When I perform hg status it seems many files are marked as modified due to the change in line ending resulted from the Windows to Unix migration.
In git one can do the following to resolve this but what is the equivalent solution for mercurial hg?
git config --global core.autocrlf true
Maybe this extension does the work. Check out EolExtension
Enable Eol extension (in your .hgrc file):
[extensions]
eol =
And then override the OS default carriage return:
[eol]
native = CRLF
only-consistent = False
I don't understand why a commit in EGit is changing the whole file.
Yes, I'm on Windows, and I have core.autocrlf=true set globally in /etc/gitconfig.
Here's what I don't understand:
the working copy starts off with DOS line endings both before and after edit
When I edit the file in Eclipse and look at git diff through the command line, I only see the lines that I changed in the diff.
If I git add and git commit through the command line as well, the git diff HEAD^ shows only the lines I changed.
When I do the commit through Eclipse/EGit instead, git diff HEAD^ shows the entire file as changed, as if the Windows line endings were just added -- when my working copy already had DOS newlines before I touched it.
Any idea why the different behavior in EGit vs. git command line? Where else could Eclipse/EGit be mangling line endings?
I am trying to build mono on windows, but the .sh files give errors about the carriage returns :
$ ./autogen.sh --host=i686-pc-mingw32 --profile=/usr/opt
./autogen.sh: line 4: $'\r': command not found
./autogen.sh: line 6: $'\r': command not found
./autogen.sh: line 9: $'\r': command not found
The .gitattributes file has this line({cr:
*.sh crlf
I can edit and remove the cr, but then when I try to do a reset so that it will blow away the local file and reget the file from origin, the gitattributes are also blown away:
git fetch origin master
git reset --hard FETCH_HEAD
Looking at the mono repository, they have the .gitattributes like this, but none of the build instructions addresses this issue.
What is the proper way to deal with line endings when building mono on windows? Surely I'm not supposed to manually run dos2unix after everytime I pull?
Make sure that you have
git config --global core.autocrlf false
That will avoid global conversion done (in addition of the .gitattributes directive)
I can edit and remove the cr
Yes, but then you need to add and commit first, before doing the:
git rm --cached -r .
git reset --hard
Otherwise, the .gitattributes would be restored to its previous state.