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.
Related
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.
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 just read Writing good commit messages and liked it a lot. The problem is, I prefer the command line (plain ole' git).
How can I add newlines and tabs to commit messages, so as to have a "summary line" and message body (which may consist of several paragraphs)?
Does GitHub support markdown in their commit messages? After reading "Shiny new commit styles" this doesn't seem possible
git automatically spawns your preferred $EDITOR to prompt for a commit message when you run git commit. So it may be as simple as leaving -m off of your git commit command
If git launches the wrong editor, or fails to launch an editor, try setting the EDITOR environment variable to your preferred editor:
export EDITOR=/usr/bin/vim
Or, to only change the editor used by git, you can set core.editor
git config --global core.editor /usr/bin/vim
Using an editor to compose a commit message this way has a couple of further advantages. Git populates the file you are editing with a summary of the files that were changed in the commit, which should help you write a better commit message. Also, vim (and other editors) support basic syntax highlighting for this kind of file, making it even easier.
For newline, just hit enter inside quotes, like this: git commit -m "Some headline <hit enter>. Also you can use your text editor to write commit messages.
Unfortunately no, e.g. this commit with markdown for example.
When creating a git commit, you can use -m multiple times and it will create multiple paragraphs.
To quote the man page
-m <msg>, --message=<msg>
Use the given as the commit message. If multiple -m options are given, their values are concatenated as separate paragraphs
Also, as mentioned before, if you leave out the -m option, then git will open an editor (set with a command like git config --global core.editor /usr/bin/vim) in which you can type your commit message.
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?
Git noob here. Having a hard time figuring out why git shows some files changed, while Eclipse EGit does not.
When I use EGit within Eclipse and view a project, it shows no files changed. There is no little caret next to each file. When I use Git for Windows, or go to the command line and type "git status", it shows that all the files have been modified. When I type "git diff" it shows two different versions of a file, first red, then green, and there appears to be some whitespace differences, but I can't be sure, and I can't figure out how the whitespace changed in every file in the project. (Something here doesn't add up.) "git diff -w" returns nothing. "git config --global apply.whitespace nowarn" does nothing.
I might be having a basic conceptual problem with git.
In any case, why do EGit and the git command line show different results?
EGit understands the notion of Derived resources (e.g. used for generated .class files in JDT). In other words, files in derived resources are not added to version control by default in EGit. However, the command line git client does not know these markers, but relies on .gitignore files to avoid checking in generated files.
To check whether your problematic files are derived, open the file properties dialog (right click on the file in the explorer, and select Properties...), and on the Resources page check for the Derived checkbox (it should be around the middle of the dialog).
It turns out that git is playing games with newlines. It's inexplicable. Bottom line: EGit and the git command line cannot both be used on a Windows box. To get consistency, you have to use one or the other.