When I clone a project, I did git status right away and some files appear edited.
I check with git diff . and all edited files have the same message: "warning: CRLF will be replaced by LF".
I didn't even open any files.
git checkout . didn't work.
How is this possible?
On Linux new line mark it is \n, and on Windows it is \r\n, so it looks like when you clone a repository, the operating system changes \r\n to \n and you see the difference
Related
I want to always add the same files to my git repo, and I thought that having a file of files to add to git would be an easy way to do that.
How can I ask git add to read the files to be added from a file?
It is also easy to use standard cli tools to do this :
# bash:
git add $(cat file)
# xargs is standard on linux, and comes with git-bash on Windows :
cat file | xargs git add
It seems that git add --pathspec-from-file=file is just what I was looking for.
Just make sure that all lines are valid file names. And that none are empty.
Im using a windows system to push my changes to a git linux server, where users commit with macOS, could this be the problem of invalid diff changes? changes which are not changes are displayed as deleted and later on re-added as new somehow. im using sublime and also tryed netbeans with the same behaviour...
Windows and *nix based operating system use different line ending character in files. In your case you are adding the Windows Carriage return character in your file and on MacOSX they are removed.
On your Sublime you can change the line ending character on save to match the MacOSX's line ending . See is there a way to convert files line ending on saving. This way you will not see these changes.
You could also instruct git to automatically do the conversion with the core.autocrlf config. See GitHub dealing with line endings
GitHub suggests that you should make sure to only use \n as a newline character in git-handled repos. There's an option to auto-convert:
$ git config --global core.autocrlf true
Of course, this is said to convert crlf to lf, while you want to convert cr to lf. I hope this still works …
And then convert your files:
# Remove everything from the index
$ git rm --cached -r .
# Re-add all the deleted files to the index
# You should get lots of messages like: "warning: CRLF will be replaced by LF in <file>."
$ git diff --cached --name-only -z | xargs -0 git add
# Commit
$ git commit -m "Fix CRLF"
As Per Git Config Manual
core.autocrlf
Setting this variable to "true" is almost the same as setting the text
attribute to "auto" on all files except that text files are not
guaranteed to be normalized: files that contain CRLF in the repository
will not be touched. Use this setting if you want to have CRLF line
endings in your working directory even though the repository does not
have normalized line endings. This variable can be set to input, in
which case no output conversion is performed.
The remote repo has mixed cr/lf lineendings, thought it was unix, now i just set the original lineending if it happens again.
I'm trying to do something very simple: check out a repo that has CRLF endings (and no .gitattributes) file, and end up with native (LF) line endings. I don't even want to commit back.
I've read Github's suggestion, and Tim Clem's article, but mostly they seem aimed at Windows developers.
I've tried this:
$ git config --global core.autocrlf=input
$ git clone https://github.com/DennisSchiefer/Project-OSRM-Web.git
But no - the file I care about, OSRM.Config.js, still has CRLF endings.
Trying core.autocrlf=true didn't help.
Even adding and committing a .gitattributes file (then git rm --cached -r . && git reset --hard) doesn't help.
I can't find any combination that will actually leave LF line endings on this file.
core.autocrlf will force git to process all text files.
If OSRM.Config.js is not processed, that means Git deems it binary.
See:
"How to determine if Git handles a file as binary or as text?"
"Why does Git treat this text file as a binary file?"
Even with a .gitattributes with *.js text, that would still keep crlf.
But with *.js eol=lf, that would actually force the conversion.
See "Can git's .gitattributes treat all files as binary except a few exceptions?".
So I want to compare this folder http://cloudobserver.googlecode.com/svn/branches/v0.4/Boost.Extension.Tutorial/libs/boost/extension/ with this http://svn.boost.org/svn/boost/sandbox/boost/extension/. I want to get a diff file as a result. These folders are under svn control but I'd prefer git styled diff file (like one shown here) I tried git diff but it seems not to work that way for web folders. So how to do the same thing with one command on Linux?
Update:
So we had a great answer. But it works strangely - it seems to me it shows that all files (same files) have all theire contents replaced with very same contents (while I know for sure that there were only like 3-4 code lines changed at all)...
Update 2:
To achieve what I really needed (dif file with only really changed lines, with git styling, on Linux) do:
$ svn export http://cloudobserver.googlecode.com/svn/branches/v0.4/Boost.Extension.Tutorial/libs/boost/extension/ repos2 --native-eol CRLF
$ svn export http://svn.boost.org/svn/boost/sandbox/boost/extension/ repos --native-eol CRLF
$ git diff repos repos2 > fileWithReadableDiff.diff
Once you have the source trees, e.g.
diff -ENwbur repos1/ repos2/
Even better
diff -ENwbur repos1/ repos2/ | kompare -o -
and have a crack at it in a good gui tool :)
-Ewb ignore the bulk of whitespace changes
-N detect new files
-u unified
-r recurse
You urls are not in the same repository, so you can't do it with the svn diff command.
svn: 'http://svn.boost.org/svn/boost/sandbox/boost/extension' isn't in the same repository as 'http://cloudobserver.googlecode.com/svn'
Another way you could do it, is export each repos using svn export, and then use the diff command to compare the 2 directories you exported.
// Export repositories
svn export http://svn.boost.org/svn/boost/sandbox/boost/extension/ repos1
svn export http://cloudobserver.googlecode.com/svn/branches/v0.4/Boost.Extension.Tutorial/libs/boost/extension/ repos2
// Compare exported directories
diff repos1 repos2 > file.diff
I had a developer 'revert' a file by deleting it from the repository and re-adding it. We now have a current file with no history. Is there a way to get back the deleted file. With it having the same name as existing file, how should I proceed? Yes, I have tried to read the docs but can't seem to get the right combination of actions to take.
delete the file in your working copy
in the repository browser, go to the revision where the original file still existed (i.e. before it was replaced)
right-click on that file in that revision in the repository browser, execute "copy to working copy"
specify the path in your working copy as the "copy to"-target
Now you have your file back including the history.
see this thread here...
examining history of deleted file
to resurrect your file you can
svn copy url/of/file#lastrevisionthefileexisted -r lastrevisionthefileexisted path/to/workingcopy/file
On Linux, I solved the problem by following the steps on the command line:
svnadmin create TEST
svn co https://URL/svn/codes/JarLib/
Delete file or directory which is re-added
svn delete https://URL/svn/codes/JarLib/XXXX.jar -m "XXXX.jar history resurrect operation"
svn update
Use 'svn copy' command to get deleted file/directory with HISTORY. Revision number must be deleted file's/directory's last revision number!!!
svn copy https://URL/svn/codes/JarLib/XXXX.jar#22467 -r 22467 XXX.jar
Operation below will add XXXX.jar to your Working Copy then commit the changes.
svn commit -m "deleted file/directory is resurrected"
To control:
Go to SVN Server and use svnlook command like:
svnlook history /svn/repos/codes /JarLib/XXXX.jar --show-ids