In my repository, which has mixed line endings.
I am using Mac OS X, and git 1.8.3.1
I would like to renormalize this repository so that every file has line endings that agree with the .gitattributes file.
To this end, I have checked out the latest change:
git checkout origin/develop
git reset --hard
git rm -rf .
git rm --cached -rf .
rm .git/index
git checkout HEAD .gitattributes
git reset --hard
git status
Now, git rm --cached -rf . will cause an error, but I am being very paranoid with the above command. (On my machine, those commands were on one line, ignoring exit codes)
I repeat the command many times. (Ie, UP; ENTER; UP; ENTER; UP; ENTER;...)
Most of the time, I have a clean check out, which is not what I am expecting.
However, roughly once every ten times, I find that I get three files (which seem to be correctly renormalized). The remaining times there is no renormalization.
The output of such a file that gets renormalized (Ie, is 'modified') is:
$ file source/RemoveDuplications.cs
source/RemoveDuplications.cs: UTF-8 Unicode (with BOM) C++ program text, with CRLF line terminators
My git attributes file has a fair number of entries, but the relevant one is here:
* text=auto
*.cs text eol=crlf
What might be going wrong here?
It looks like what you are doing may be overly complex. You shouldn't need to remove all files from the repo or delete the index by hand. Have you tried:
git rm --cached -r . # remove everything from the index
git reset --hard # replace files w/ corrected line endings
git add . # stage all changes
git commit -m "Normalize line endings"
If this isn't working for you I'd re-check the values of your core.autocrlf and .gitattributes. You may need to clear those, reset your shell, check out the repo again and then reset them to get the behavior you want.
Here are some other resources that might help:
Github - dealing w/ line endings
A similar question here with multiple answers to consider
A good post about the pros/cons of this approach vs git filter-branch
You could always use something like a sed script to edit the files and then recommit them to see if this keeps happening. If you do this from the command line, you should, using the proper regex, be able to pull out any hidden characters that might be causing your problem.
Related
So I'm running git in Windows with a repo that runs on *nix, where git checks out Windows-style newlines (line ending CRLF) but commits *nix-style (LF), however I can't get a diff/apply to work without some fatal snag no matter what I've tried.
For example, I run a diff to a file from one commit to another like:
git diff commit1 commit2 > patch.diff
But when I run git apply patch.diff, I get errors like:
trailing whitespace
patch failed
patch does not apply
I've tried setting git config --global core.autocrlf true, tried git apply --ignore-space-change --ignore-whitespace patch.diff, and git config --global core.whitespace cr-at-eol, and even if it works, the apply shows that almost every line of code was changed just because of the newlines.
If I check the applied patch in something like Git GUI or WinMerge, it shows the proper changes just because they ignore newline changes, but either the diff or apply command is considering the newline differences, and everything I've found on the web to try just doesn't end up with a proper result.
I found something about git rm --cached -r . but it requires committing all files with "fixed" newlines... which isn't feasible for our project (and shouldn't be necessary).
Am I just not running the right combination or commands and options or what am I supposed to do?
my git repository is quite big and I would like to bring its size down by removing some big files, which I added in the past and already removed later on, but which are still in the git history. Now I found the git filter-branch --tree-filter command. So i tried this:
git filter-branch --tree-filter 'DEL /content/de/files/bigfile.zip' --all
(I'm on Windows).
But the result of invoking this command is:
fatal: ambiguous argument '/content/de/files/bigfile.zip'': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
I don't know, what to do. In the current working directory, the file is indeed not present. But it is still there in a couple of old commits in the history. My understanding was, that the command would remove the file from every commit.
So the actual mistake in my version was, that I used single quotes instead of double quotes. Seems like, at least on Windows, you have to use those.
That said, the comments from jthill and the answer from Roberto probably present better solutions to the task at hand.
You might want to consider the BFG, a faster and simpler alternative to git filter-branch. The equivalent command is :
$ bfg --delete-files bigfile.zip
https://rtyley.github.io/bfg-repo-cleaner/
Disclaimer : I am the author of the BFG
Up until now I was able to do git add -p in my repo. Git would ask me for the hunks I'd like to add separately ignoring all whitespace and/or line endings (crlf etc.)
I now installed the most recent version of git for Windows (git version 2.7.1.windows.2) and for some reason, whitespace is not ignored anymore.
Whenever I git add -p now, the whole changed file is displayed (prefixed with minus signs in red, then again prefixed with plus signs in green), followed by the usual prompt
Stage this hunk [y,n,q,a,d,/,e,?]?
So basically I'm not presented hunks anymore but complete files, making the feature pretty much useless.
What settings do I need to revert to/change to get "real" hunks again?
Edit: git diff has the same problem (as expected), git diff --ignore-space-at-eol and git diff --ignore-all-space give the desired output.
I have been unable to reproduce the problem since I committed the files that weren't shown as hunks anymore.
I have several repos that have been converted from SVN. Each time I attempt to run git rebase -i master, the message defaults to noop. When saving, I get Successfully rebased and updated refs/heads/master which seems suggest it has done something, but all commits are still present.
I did find this question but the solution doesn't appear to apply to OsX.
I also tried git rebase -i HEAD~3 on a project with 3 commits, but I get:
fatal: Needed a single revision
Using rebase -i HEAD~2 will and rebases correctly, but I need to squash these to a single commit with the init commit date.
Interestingly, the rebase consistently misses the earliest commit on each project. In each it it the only commit not assigned to my user (it is a system commit), so I wonder if that is related.
The question cited has a possible answer: Setting the shell variable IFS (what characters are interpreted as separating "words" in shell lines, in this case separating arguments) makes two arguments interpreted as one (obviously unknown), and the (internal) command fails with the cited result.
See to what (if anything) IFS is set (echo $IFS). Try (unset IFS; git rebase -i HEAD~3) (the parentesis are required here in bash(1), OS X shell could be different, but I doubt it).
My company has a policy that all checkins to a particular project must follow a specific multi-line template for git commits. How can I most simply create a single commit message that has multiple lines from the command line in Windows?
This is almost exactly a duplicate of "Add line break to git commit -m from command line" except that this question is specific to Windows/cmd.exe, while that question is related to bash.
Either create a file that contains your commit message in the right format and use git commit -F <message_file>, after which you can continually edit and reuse that same file, or create a template file and use git commit -t <template_file> to open your editor with the pre-cooked template to be filled in. The second option can be made permanent by setting the commit.template configuration variable, so you don't need to use the -t ... bit on every commit. See the git commit manual page (git help commit, if your git is installed correctly, or search online) for more information.
You can create multiline commit message like this:
C:\> git commit -m "Line 1"^
More?
More? "Line 2"^
More?
More? "Line 3"
Note, that the circumflex character is only on odd lines.
git commit -m "Subject" -m "Description..."
You can also use interactive rebase and then reword for editing the commit's message.
Type git commit -m "doesnt really matter whats here" and then git rebase -i HEAD~1, replace pick with r or reword, save and then edit the message.