Add, commit to a local branch repository,
git add *.*
git commit -m "msg"
I push code to remote branch
git push branch
I get the same error on a Xcode specific file
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: abc/abc.xcodeproj/project.xcworkspace/xcuserdata/axz.xcuserdatad/UserInterfaceState.xcuserstate
I have to add and commit that file again and then push works
Next I merge my branch into main
git checkout main
git merge branch
I get same error on the same file
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified: abc/abc.xcodeproj/project.xcworkspace/xcuserdata/axz.xcuserdatad/UserInterfaceState.xcuserstate
I have to add and commit the file and then push
git push
Then it works.
I don't know why this specific file does not get included in the initial add/commit/push and I have to perform add/commit/push separately on this specific file.
This file UserInterfaceState.xcuserstate is specific to user I assume. As I work in team, so will I be overwriting someone else's UserInterfaceState.xcuserstate file? Can someone explain?
xcuserdata should be ignored from source control, you can add it to your .gitignore.
xcuserdata/
% git checkout branch02_vr
M r2nr/r2nr.xcodeproj/project.xcworkspace/xcuserdata/vhrao.xcuserdatad/UserInterfaceState.xcuserstate
M r2nr/r2nr.xcodeproj/xcuserdata/vhrao.xcuserdatad/xcdebugger/Breakpoints_v2.xcbkptlist
M r2nr/r2nr/Base.lproj/Main.storyboard
Switched to branch 'branch02_vr'
on my branch branch02_vr:
% git add *.*
% git commit -m "message"
% git push -u origin branch02_vr
% git status
On branch branch02_vr
Your branch is up to date with 'origin/branch02_vr'.
nothing to commit, working tree clean
Successful so far.
Then I wanted to merge my branch02_vr into main
% git checkout main
% git merge branch02_vr
Updating dd5bfe5..0284d6d
error: Your local changes to the following files would be overwritten by merge:
r2nr/r2nr.xcodeproj/project.xcworkspace/xcuserdata/vhrao.xcuserdatad/UserInterfaceState.xcuserstate
Please commit your changes or stash them before you merge.
Aborting
% git commit -m "message"
On branch main
Your branch is up to date with 'origin/main'.
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified: r2nr/r2nr.xcodeproj/project.xcworkspace/xcuserdata/vhrao.xcuserdatad/UserInterfaceState.xcuserstate
no changes added to commit (use "git add" and/or "git commit -a")
I dont understand the error here. So I just follow git prompts to fix the issue
% git add r2nr/r2nr.xcodeproj/project.xcworkspace/xcuserdata/vhrao.xcuserdatad/UserInterfaceState.xcuserstate
% git merge branch02_vr
error: Your local changes to the following files would be overwritten by merge:
r2nr/r2nr.xcodeproj/project.xcworkspace/xcuserdata/vhrao.xcuserdatad/UserInterfaceState.xcuserstate
% git stash
% git merge branch02_vr
Looks like this worked. I go to remote main and verify the code changes are merged from brnach02_vr into main
% git stash pop
warning: Cannot merge binary files: r2nr/r2nr.xcodeproj/project.xcworkspace/xcuserdata/vhrao.xcuserdatad/UserInterfaceState.xcuserstate (Updated upstream vs. Stashed changes)
Auto-merging r2nr/r2nr.xcodeproj/project.xcworkspace/xcuserdata/vhrao.xcuserdatad/UserInterfaceState.xcuserstate
CONFLICT (content): Merge conflict in r2nr/r2nr.xcodeproj/project.xcworkspace/xcuserdata/vhrao.xcuserdatad/UserInterfaceState.xcuserstate
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
(use "git push" to publish your local commits)
Unmerged paths:
(use "git restore --staged ..." to unstage)
(use "git add ..." to mark resolution)
both modified: r2nr/r2nr.xcodeproj/project.xcworkspace/xcuserdata/vhrao.xcuserdatad/UserInterfaceState.xcuserstate
no changes added to commit (use "git add" and/or "git commit -a")
The stash entry is kept in case you need it again.
I dont understand what is going on with xcuserstate file
% git checkout branch02_vr
r2nr/r2nr.xcodeproj/project.xcworkspace/xcuserdata/vhrao.xcuserdatad/UserInterfaceState.xcuserstate: needs merge
error: you need to resolve your current index first
I don't understand what is going on with the xcuserstate and the errors that are coming from it.
I am working in a team and do not want to mess up others files. I cannot checkout my branch02_vr again. Can someone explain and help?
My question is about why folder name capitalization is changing from ServerCom to ServerCOM when I stage my changes for this folder? Does git have a configuration to do this?
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Untracked files:
(use "git add ..." to include in what will be committed)
ServerCom/text.txt
nothing added to commit but untracked files present (use "git add" to track)
$ git add ServerCom/text.txt
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD ..." to unstage)
new file: ServerCOM/text.txt
For some reason, after cloning a repository and changing branch I had one jar file marked as modified (without being modified) and I can't seem to un-modify the file (which prevents merging branches.
PS D:\src\expm> git status
On branch epic-my-wallet
Your branch is up-to-date with 'origin/feature-01'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: Test/Selenium/selenese-runner.jar
no changes added to commit (use "git add" and/or "git commit -a")
I tried to undo with the checkout command
PS D:\src\expm> git checkout -- .
git status output the same exact message as previously.
I tried to reset it from HEAD with
PS D:\src\expm> git checkout -f HEAD
Your branch is up-to-date with 'origin/feature-01'.
Please note that jar files are flagged as handled by LFS in the .gitattributes file
*.jar filter=lfs diff=lfs merge=lfs -text
Not quite sure on the next step here. The file has not been modified since its commit months ago.
edit
I should add that today we tried to reset the cache with git rm . -r --cached and removed the LFS cache as well (physically remove the .git/lfs folder) and re-download the files with git reset --hard.
Due to your git setting to handle end of line, which should be to 'autocrlf', git modify/corrupt the jar file at checkout!
You should add a '.gitattributes' file in your repository where you set the 'jar' files as 'binary' and git will no more try to convert end of lines.
That's the recommended way to handle end of line in a git repository to solve such problems...
It seem the problem was linked to Git LFS in some way. We upgraded both Git (from 2.8.4 to the current at 2.9.3) and Git LFS (from 1.2.1 locally to the latest 1.3.1 at the moment). Then deleted and re-added the jar file.
We did a clean clone on a new folder after that and the problem seemed to be resolved. Could be the upgrade of git + lfs that resolved the issue.
I've converted an SVN repository to Git by following this tutorial. And now cannot seem to extract a sub-repository like suggested in this answer.
Forgive the long post but most of the text is the nicely formatted git output.
OS: Windows 8
Command line: MinGW
Git version: 1.8.1.msysgit.1
The process of extracting a subrepository doesn't seem to work unless you have a clean staging area and no modified files.
git status tells me that I have a modified file even though this is a fresh SVN import. Ok, let's just try and get rid of it.
Try and revert the file.
user$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")
user$ git checkout -- "folder with space/folder/toolbar.png"
user$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")
This didn't work, but I don't really care if I commit it so I'll try that next.
user$ git commit -a -m "Testing if committing fixes it"
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")
user$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")
Committing by skipping staging doesn't work, so let's try and stage it first.
user$ git add "folder with space/folder/toolbar.png"
user$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")
Doesn't work, so I'm stumped... Go and ask someone smarter.
I'm new to git but am familiar with Hg and have been reading this online tutorial to get myself started.
It is entirely possible that I've messed up a simple command.
Already tried:
I looked around for a solution to my particular problem but have had little luck. I've stumbled across this answer which seems related but does not quite fix my problem.
Edit: Things that might be interesting
This is the part that confuses me. I've pushed this repo a while ago into an online repository. After a fresh clone the repo still thinks that the file is modified (i.e. git status returns the same result, and I've already set git config --global core.autocrlf false and verified by running git config --global core.autocrlf which indeed returns false).
Edit 2: Fix found, but the problem is still not understood
I've managed to fix the repository by simply removing the file from the system, the staging area and then committing the changes.
After this to get the file back I've simply copied it back and committed it to the repository.
The problem, though fixed has only confused me more.
While I was playing around with removing the file I noticed that if I reset the repository to the HEAD, whose last commit has removed the file, git status would indicate that nothing has changed and that the file is not tracked but the file would be restored in my working tree. This is odd considering that it is flagged as removed in git...
Only after removing it a second time, even though git no longer remembers it, did I manage to actually remove it so that git reset and git reset --hard don't restore the file.
If somebody can please explain how I got into this state and if it is a bug in git or normal behavior I would greatly appreciate it.
My suspitions
I've lost the sequence of commands that I used but what happened went something like this:
The file is Images/toolbar.png, and I've navigated into the Images folder.
After I deleted it from the file system git detected the change like so:
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted: toolbar.png
# deleted: ../images/toolbar.png
#
Note the fact that the images folder is not capitalised! This is being run in Windows which ignores the path case. I suspect that this might be a part of the problem...
I'm really confused but my problem is gone. So this post remains only as a curiosity, although I can't replicate the behaviour it lives in the conversion from SVN somewhere.
I had a similar issue a while back.
Did the capitalization on this file, or the directory it was in change at any point?
I had a directory with a capital letter that was changed to all lowercase (let's say it went fromt /Foo to /foo). It gave me all the same problems you've described.
Whenever I modified a file, it gave me similar output to this:
# modified: bar.txt
# modified: ../Foo/bar.txt
I also had the same problem where committing or resetting wasn't producing any results.
I think the cause of the problem is that Windows file paths are not case-sensitive, but Unix ones are. Since a lot of these command-line tools like Git are developed on Unix-y systems, they sometimes don't handle this difference well, and can get confused when a file is added as Foo/bar.txt and foo/bar.txt. I think this makes Git think there are two different files, where there's actually only one.
My eventual fix was the same as yours, remove the entire directory from history, then re-adding it (and never changing the capitalization ever again). This also caused the same weirdness you described where I had to remove it twice before it took.
Anyway, I know this isn't a definitive answer, but I've since been able to recreate the problem, so I'm pretty sure that's what caused it (at least for me).
I had a similar issue caused by having two files with the same name as my computer saw it.
Message I kept getting:
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: images/contact_seller.GIF
#
It happened because the repo's initial commit was done from MacBook that is formatted case-sensitive and the error was appearing on my iMac that was formatted case-insensitive.
On the case-sensitive machine you could see two files
SwedishChef$ ls images/contact_seller*
images/contact_seller.GIF images/contact_seller.gif
Which isn't valid on the second machine so git had to do something about it.
I just had to rename the file and commit those changes.