I'm having a hard time understanding some git/DCVS concepts. Here's what happened:
I created a git project, and imported it from an SVN repo
I made some commits
I wanted to experiment something, so I created a branch called constants-update
I switched to constants-updatebranch, moved some files, deleted others and added many more
I committed to this branch
Now I'm trying to switch to my master branch using git checkout master
I got this error: error: You have local changes to 'src/groovy/Constants.groovy'; cannot switch branches.
My understanding of DCVS is that I can switch branches at will, even if some branch has more or less files than the others, as long as I commit my files. I've tried committing with git commit -a and switching to master branch, but I have the same error.
As a side note, when I commit git warns me that LF will be replaced by CRLF and warns me about some trailing whitespaces also; after I commit I do a git status and a bunch of files always appear as #modified ....
Is this related to git/windows, or I do not understand correctly what it is supposed to happen? I just want to switch to my master branch without losing my changes in the other branch.
Lookup git-stash for changing branches while there are unsaved changes in the current branch.
You are correct in your thinking about how this should work.
However, it sounds like git is having issues with the line endings, and it thinks all your files are modified even when they aren't. I don't use git on Windows, but I was going to suggest the "core.autocrlf" option to make the crlf handling work. However, the following blog entry indicates that this might not be a good idea: http://weierophinney.net/matthew/archives/191-git-svn-Tip-dont-use-core.autocrlf.html
I solved the problem hacking my pre-commit hook (commenting these lines in .git/hooks/pre-commit with a #):
# if (/\s$/) {
# bad_line("trailing whitespace", $_);
# }
Just use the following option in .gitconfig file which resides in your users directory.
[core]
autocrlf = true
And it will solve the issue.
Related
After an "unsuccessful" git pull on my local master, an error prevents to switch back to master:
C: repo_folder> git checkout master
error: invalid path '?'
The ? must be because it is a keybase repo.
From another branch where I checked out some files of the last commit:
C: repo_folder> git diff origin/master --compact-summary
"\004" (gone) | 1902 ---------------------------
some irrelevant stuff | (num) -
The removed file "\004" (that was never present in my local) seems to come from some Mac OS (someone might have opened a csv and a temporary file was created when that user did the commit and pushed?).
observe that the file that is marked as (gone) is to be removed by git
the problem is that the filename has characters that are not compatible with the Windows file system and that the file never existed in my local Windows repo.
If I clone from a Linux platform, I can checkout to master with no problems. However, in Windows, there's no way back to the master branch.
Any ideas on how to solve this issue? (already tried some posts with no success)
I can't really understand how it comes git doesn't even allow me to checkout to master. Should I file a bug report?
Alternatively, perhaps I could create a new master branch and get rid of the current one.
EDIT
A clone from Linux helped to identify that the file ? was actually there.
This could be checked directly from Windows as well by using the command: git ls-tree origin/master (which was showing the original problematic name "\004")
The accepted answer includes the case where you want to save the content of the file, while in my case I only wanted to get rid of it. So in my case, I have just deleted the file from Linux, committed and pushed the change, and did a git fetch origin master:master to fetch my local master with being checked out in another branch (as I was not able to checkout to master). This finally did the trick and I could checkout to master.
Hope this clarifies to someone with a similar problem.
? (or maybe it's EOT) cannot be used as a filename on Windows. The file will have to be deleted or renamed. You can do this most easily by cloning on a system which does allow ? and making the fix.
If you only have Windows, Fixing Invalid Git Paths on Windows offers a method of renaming the file without checking it out. In brief...
git checkout origin/master -f to get the checkout without the problematic file.
Make a branch.
Add and commit the "deleted" problematic file.
Use git ls-tree HEAD^ to get the ID of the problem file.
Use git cat-file -p <ID> to get the content of the problem file.
Put the content into a new file.
Add and commit.
I am seeing strange behavior on Mac with git. I dont see this happening on Windows. Using git v 2.19.1 on mac and 2.18.0.windows.1 on windows.
I work in a crossplatform team, so some of us use Windows, others use Mac. I use both.
Here is the scenario I see:
I work on my feature branch for few days and like to make sure I update my branch with latest changes on remote so I always work on most recent version of remote. So, I daily do following to reduce chance of conflicts and stay on most recent version:
git checkout develop
git fetch origin
git merge origin/develop
git checkout my-feature
git merge develop
Once that is done, I apply my changes to my-feature branch but I notice that git behaves very strangely on Mac. Here is what happens:
I added some changes
I did not stage anything yet, so no git add . was issued
I do git status and I see lots of files as if they got modified and staged by me even though I did neither modified nor staged them.
For example, git status shows my .gitignore file now as:
me$ git status
On branch my-feature
Your branch is up to date with 'origin/my-feature'.
Changes to be committed:
new file: .gitignore
On Windows, this does not happen and since I did not modify this file, it will not show in git status at all. My modified files show as needed to be added which is how it should behave.
Why would files I never touched be viewed by git on Mac as somehow modified and staged?
In mixed dev environments (like I work in also) I see this behavior when 'line endings' are mismatched. The best way to solve this is to update your .gitconfig file.
I encourage everyone on the teams I work within to add the following to their .gitconfig file. You can add a .gitconfig to each repo, just like a .gitignore, and/or each developer can set it within their git global config file.
[text]
eof=lf
There are different options, but the key is for the whole team to use the same line endings when committing & pulling.
Here is my gitconfig, per the request below.
[User]
name = Ben Horgen
email = xxx#xxxxxxxx.com
[text]
eof=lf
[core]
autocrlf = input
[pull]
rebase = true
[push]
default = simple
"Out of the blue" I've started having this issue with a git repository that I have hosted on GitHub.
Whenever I pull a remote branch to my computer (even on the first clone of the repository) an arbitrary (?) set of files appear as "Changes not staged for commit". I am running on Windows 8.1 and using SourceTree alongside Git Bash as git clients.
An examination of the changes in these files shows that nothing has changed in them, except, maybe, the line endings. I don't know how to view the line endings when diffing so can't be sure.
When I try to "discard" these changes, it simply doesn't work. git reset --hard simply has no effect and the changes remain in place.
Why is this happening? How can I make it go away? :)
PS - When I run git config -l I see core.autocrlf=true appear 3 times in the list.
PPS - I have a .gitattributes file in the root of the repository. Deleting it does not have any effect on the above symptoms. It was first added a few days ago. It's all commented out except for * text=auto in the beginning of the file.
UPDATE:
I've found the minimum steps to reproduce my issue:
I open a file in a text-editor, add a single space somewhere and save it.
The file appears under "Changes not staged for commit" (obviously).
I remove the single space from the file and save it.
The file remains under "Changes not staged for commit" even though both SourceTree's diff and Kdiff3 show that the file is binary equal to its previous version.
Please note that the file in this example had CRLF line endings before I edited it and after I edited it - I don't understand why git insists on marking the file as changed.
UPDATE 2:
Running git diff --raw MyProject/app.config where MyProject.app/config is one of the files marked as changed gives:
:100644 100644 b960510... 0000000... M MyProject/app.config
The fact that the second SHA1 is all zeroes looks like a clue to me - but I don't know what it means.
This is a common problem when you set core.autocrlf after the fact. You can try this procedure from GitHub help. Another easy solution is to just clone a new local copy of the repository, which can also be a good troubleshooting step if you're still having problems.
UPDATE 3: I was able to resolve my issue by removing the .gitattributes file from the root of my repository.
The most likely suspect for having added this file into the repo in the first place is Visual Studio 2013 are per this Microsoft Connect issue.
I still don't understand why having this file (with this core.autocrlf=true in it) caused the behavior that I observed. If anyone has a good explanation, please post it as an answer and I will accept it.
Following the github article on dealing with line endings you can see that setting text=auto on the .gitattributes file tells git to "handle the files in whatever way it thinks is best." Seeing that the rest of the file was commented, and you had a star on text=auto, this was applied on everything. I suppose that in your case, what git thought was best, turned out to be the wrong choice.
I have searched everywhere and tried various solutions but am still getting the error:
Your local changes to the following files would be overwritten by merge
i have nothing to commit as status tells me the following:
# On branch develop
# Your branch is behind 'origin/develop' by 1 commit, and can be fast-forwarded.
# (use "git pull" to update your local branch)
#
nothing to commit, working directory clean
So then I do a git pull, then get the following:
Updating 67020e6..6dd23de
error: Your local changes to the following files would be overwritten by merge:
app/filename.php
Please, commit your changes or stash them before you can merge.
Aborting
But as I have nothing to commit and if I do a git stash I get No local changes to save
So how can I fix the problem and download and update my local machine with my remote amends.
Bit of history incase:
I have to local machines one at home and work I have done the amends at home and pushed them and I am now trying to update my local work machine with these updates.
EDIT UPDATE
As I cannot answer my own question for a while I found what for me solved this answer:
on the branch I wrote:
git reset --hard
Then the pull worked.
While looking around i tried the following that seemed to fix my issue at the time.
While on the branch i wrote.
git reset --hard
Had you ever previously done git update-index --assume-unchanged <file>? That could be a potential reason for your situation.
To fix, you do git update-index --no-assume-unchanged <file>. Then you should be able to stash your changes and continue with the merge.
Faced exactly the same problem. I was used to CVS before I started exploring git. I think running git pull --rebase origin master is the way to go for the kind of workflow that you and I use.
Refer to https://www.atlassian.com/git/workflows#!workflow-centralized for a more detailed explanation. I definitely know the answer is somewhere in that article, but I didn't understand the article completely.
I tried to do a search for my issue and the closest thing that I could is this.
git Status Shows Same File Twice - But with different path slash styles
But it doesn't seem to be the same issue I have.
I was doing a commit and noticed that the same file was listed twice but with different case. For instance, Directory/resource.h and Directory/Resource.h. Now there is only one file in the directory resource.h. If I look at the file through Git Extensions they look exactly the same. There doesn't seem to be another hidden file, there is only one file.
So I tried to fix this by removing the resource.h file, committing, and then adding the file back and recommit again. Only one file showed up as added. I thought I fixed the issue, but now if I try to checkout a different branch I get the following error.
error: The following untracked working tree files would be overwritten by checkout:
Directory/Resource.h
Please move or remove them before you can switch branches.
Aborting
Done
I don't really have any idea what to do from here, I've only been using Git for a few months and I haven't had to do anything more complicated than merging branches and pushing and pulling.
This can happen in Windows if you have a repo with ignorecase = false and rename a file without using git. To fix, this should work
git mv -f Resource.h resource.h
git commit -m 'fix case'
and this should prevent it from happening again.
git config core.ignorecase true