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
Related
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 have got this working as a difference tool with the following setup:
Diff Command: C:\Program Files (x86)\ExamDiff Pro\ExamDiff.exe
Arguments: $LOCAL $REMOTE
If I set similar for the merge settings:
Diff command: C:\Program Files (x86)\ExamDiff Pro\ExamDiff.exe
Arguments: /merge $REMOTE $BASE $LOCAL
I get an ExamDiff console window come up, sort of like an info window, but not the GUI as expected.
If I construct the merge command manually and run it at the command line, it works no problem, so I think it must be something SourceTree is doing.
If anyone has this working and can help, it would be much appreciated!
I found a webpage for general usage of ExamDiff Pro with git here:
http://www.prestosoft.com/edp_versioncontrol.asp
From that I had the idea to try this:
Diff Command: C:/Program Files/ExamDiff Pro/ExamDiff.exe
Arguments: //merge $REMOTE $BASE $LOCAL //o:$MERGED //dn1:Theirs //dn2:Base //dn3:Yours //dno:Output //nh
The //nh stands for no history and keeps ExamDiff from storing repo paths in it's diff history. The same can be added to the diff comand's arguments.
Worked for me, hope it works for you. Cheers
PS: note there's double slashes in front of the merge command
Starting git 2.9 (June 2016), you won't have to do anything more that
git config --global merge.tool examdiff
git mergetool --tool=examdiff
See commit 35d62bb, commit e36d716 (25 Mar 2016) by Jacob Nisnevich (jacobnisnevich).
(Merged by Junio C Hamano -- gitster -- in commit 34e859d, 13 Apr 2016)
"git mergetools" learned to drive ExamDiff.
mergetools: add support for ExamDiff
The answer given by Thomas did work only partially for me. It didn't work for files in subdirectories. After adding "Quotes" around the filenames and after reading the page http://www.prestosoft.com/edp_versioncontrol.asp I came up with:
Diff Command: C:/Program Files/ExamDiff Pro/ExamDiff.exe (same as Thomas' version)
Arguments:
-merge "$REMOTE" "$BASE" "$LOCAL" -o:"$MERGED" -dn1:Theirs -dn2:Base -dn3:Yours -nh
Yes, you can use -option instead of /option with ExamDiff which is quite usefull when using Unix style file paths.
BTW: If you would like to use ExamDiff as git diff-/mergetool on the commandline too, here is my config to get this working: (the config given on the above page did not work!)
In your Git Bash window, enter the following commands:
git config --global diff.tool edp
git config --global difftool.edp.cmd '"C:/Program Files/ExamDiff Pro/ExamDiff.exe" "$REMOTE" "$LOCAL" -nh'
git config --global difftool.prompt false
git config --global merge.tool edp
git config --global mergetool.edp.cmd '"C:/Program Files/ExamDiff Pro/ExamDiff.exe" -merge "$REMOTE" "$BASE" "$LOCAL" -o:"$MERGED" -dn1:Theirs -dn2:Base -dn3:Yours -nh'
git config --global mergetool.edp.trustExitCode false
git config --global mergetool.prompt false
git config --global mergetool.keepBackup false
Hint: You might need to adjust the path to ExamDiff.exe.
This works for me (SourceTree 1.6.22.0 with external git 2.6.1 64bit, ExamDiff Pro 6.0.3.12 64bit on Windows 8.1 Pro 64bit)
I have a situation where GIT is quite happy using ExamDiff Pro but Sourcetree isn't.
Sourcetree 3.3.8
Git 2.24.1.windows.2 (embedded, installed as part of Sourcetree)
ExamDiff Pro 11.0 (beta)
To start with, I followed the advice (which has already been mentioned) on http://www.prestosoft.com/edp_versioncontrol.asp#git
After much investigation, it seems that Sourcetree does not use the global git config at
C:\Users\myusername\.gitconfig
but uses a different file at
C:\Users\myusername\AppData\Local\Atlassian\SourceTree\git_local\etc\gitconfig
This is highly counter-intuitive because opening a terminal from Sourcetree and running git from the command line, it uses the first config file, but right-clicking and selecting "External Diff" it uses the second config file.
I fixed the problem by copying my settings from the first file to the second file, and now the terminal and the right-click behave exactly the same.
Anyway, I hope that helps someone.
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 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.