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?
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).
When doing git status on the command line, git lists modifications:
and then I go to Eclipse and do Assume Unchanged via menu on one of the files listed above:
and then rerunning git status on the command line again, I'm seeing that the file has been (properly) removed from the listed modifications:
I'm wondering what does this Assume Unchanged menu command equates to in terms of Git commands? What about other choices from that menu (Untrack & Replace with HEAD Revision)?
Is it possible to see the Git commands running behinds the scene in Eclipse when executing those menus?
Eclipse does not delegate to the command line but uses JGit which is a pure Java implementation of Git directly accessing the files in the .git folder. You don't need to have the command line Git installed to use Git in Eclipse.
The Assume Unchanged Git command line equivalent is:
git update-index --assume-unchanged
See also:
Git documentation: git update-index
Because Eclipse uses the same terms, the Git command line equivalents are easy to find.
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.
So at my workplace, we have many employees using a mixture of Windows and Linux systems, with Eclipse being the official IDE of choice. I'm personally using IntelliJ IDEA, but that's not really relevant... We recently switched from SVN to Git.
One of my co-workers who I am working on a project with has at least three times now managed to accidentally change all of the line endings in the whole repository when he does a merge and then push to origin. I can't figure out how he's managing to do this, but it clearly has something to do with his process of resolving merge conflicts. We're both using Windows, and the repository we're pushing to is on a Linux machine.
We both installed git from https://git-scm.com/download/win, and chose the default options (which afaik, properly handles line endings)... But could egit in Eclipse be doing something differently somehow?
What you are going to want to do is create a '.gitattributes' file in the root of your repository. This file is unique to your repository and will override any other collaborators .gitconfig settings should they have core.autocrlf, or core.eol set.
# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto
# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text
# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf
# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary
The above is an example .gitattributes file from here. Of course this will have to be configured to suit your needs.
Here are the steps to update your repository, also taken from here.
git add . -u
git commit -m "Saving files before refreshing line endings"
rm .git/index
git reset
git add -u
git add .gitattributes
git commit -m "Normalize all the line endings"
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.