I have a problem with my local branches. When I am trying to do git checkout <branch> I get this error message:
error: The following untracked working tree files would be overwritten by checkout:
... (list of files)
Please move or remove them before you switch branches.
Aborting
I think that the reason is a fact, that in current branch I've renamed/moved some files with git mv.
All the files listed in this error message are listed with old path (i.e. path before moving / renaming action). Is there any way to work around this problem? I'd like to move to my master branch now, and merge it with current branch, so after that there should be no problem, yet for now, I don't know how to successfully switch branches (and then do a merge, if there might again be some problems).
Edit:
I was able to checkout using -f option, but the problem remains, because now I can't do merge, for the same reasons (actually, now the paths are the opposite, i.e. now error message contains new paths, that were used in database branch) and I don't know an option to force git to do this merging.
I am not sure, but probably the same solution would work for both checkout and merge problem.
Following #LutzBüch comment, I am trying to show exactly what happened in this repo.
I have branches master and database. The database branch worked only on a parts strictly related to database only. This part of code remained in a directory named let's say db. At some point, I had to change this dir name to DB, so I did some git mv's. Let's follow it from last merge, when everything still worked.
git checkout master
git merge database
git checkout database
git commit
{now the renaming happens}
git mv db/. tmp/.
git mv tmp/. DB/.
git commit {no other changes were made}
{added some renaming related changes, i.e. changed paths in 2 files}
git commit --amend
{now it's becoming the standard}
git commit {multiple times}
git checkout master {fails}
Last command failed with error message mentioned earlier. All files on the list had paths with the old dirname, i.e. db. After using git checkout -f master, when I tried to do merge I received paths with DB as the dirname.
Related
Making git pull I got conflict errors:
user#os:/proects/path$ clear
user#os:/proects/path$ git pull origin frontend-4
Password for 'https://usrename#github.com':
From https://github.com/clientname/project
* branch frontend-4 -> FETCH_HEAD
error: Your local changes to the following files would be overwritten by merge:
package.json
public/js/app.js
public/mix-manifest.json
resources/js/components/common/Header.vue
resources/js/routes.js
Please commit your changes or stash them before you merge.
Aborting
user#os:/proects/path$ git stash
Saved working directory and index state WIP on main: e214191 Gigs pictures
making git stash I got conflicts with npm autogenerated files :
user#os:/proects/path$ git pull origin frontend-4
Password for 'https://usrename#github.com':
From https://github.com/clientname/project
* branch frontend-4 -> FETCH_HEAD
Auto-merging resources/js/routes.js
Auto-merging resources/js/components/common/Header.vue
Auto-merging public/js/app.js
CONFLICT (content): Merge conflict in public/js/app.js
Auto-merging public/css/frontend.css
CONFLICT (content): Merge conflict in public/css/frontend.css
Auto-merging package.json
Automatic merge failed; fix conflicts and then commit the result.
I tried to remove them first and run
npm run watch-poll
next
but I got errors :
user#os:/proects/path$ rm public/js/app.js
user#os:/proects/path$ rm public/css/frontend.css
user#os:/proects/path$ git commit -m "ignore compiled asset"
U public/css/frontend.css
U public/js/app.js
error: Committing is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.
How can it be fixed ?
I do not need decision like setting in .gitignore rules:
/public/js/*
/public/css/*
as I need to upload my css/files to server, as I do not have npm installed on server.
Answer : Find lines that prevent auto merging and then do rest
The main problem for not commiting or pushing is because of the conflicts between files
Git can handle most merges on its own with automatic merging features. A conflict arises when two separate branches have made edits to the same line in a file, or when a file has been deleted in one branch but edited in the other
There are many tools to help resolve merge conflicts, such as :
git log
git reset
git status
git checkout
git reset
#How to identify merge conflicts
As we have experienced from the proceeding example, Git will produce some descriptive output letting us know that a CONFLICT has occcured. We can gain further insight by running the git status command
$ git status
On branch main
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: merge.txt
The output from git status indicates that there are unmerged paths due to a conflict. The merge.text file now appears in a modified state. Let's examine the file and see whats modified.
$ cat merge.txt
<<<<<<< HEAD
this is some content to mess with
content to append
=======
totally different content to merge later
>>>>>>> new_branch_to_merge_later
Here we have used the cat command to put out the contents of the merge.txt file. We can see some strange new additions
Think of these new lines as "conflict dividers". The ======= line is the "center" of the conflict. All the content between the center and the <<<<<<< HEAD line is content that exists in the current branch main which the HEAD ref is pointing to. Alternatively all content between the center and >>>>>>> new_branch_to_merge_later is content that is present in our merging branch.
#How to resolve merge conflicts using the command line
The most direct way to resolve a merge conflict is to edit the conflicted file. Open the merge.txt file in your favorite editor. For our example lets simply remove all the conflict dividers. The modified merge.txt content should then look like:
this is some content to mess with
content to append
totally different content to merge later
Once the file has been edited use git add merge.txt to stage the new merged content. To finalize the merge create a new commit by executing:
git commit -m "merged and resolved the conflict in merge.txt"
Git will see that the conflict has been resolved and creates a new merge commit to finalize the merge.
#Git commands that can help resolve merge conflicts
General tools
git status
The status command is in frequent use when a working with Git and during a merge it will help identify conflicted files.
git log --merge
Passing the --merge argument to the git log command will produce a log with a list of commits that conflict between the merging branches.
git diff
diff helps find differences between states of a repository/files. This is useful in predicting and preventing merge conflicts.
Tools for when git fails to start a merge
git checkout
checkout can be used for undoing changes to files, or for changing branches
git reset --mixed
reset can be used to undo changes to the working directory and staging area.
Tools for when git conflicts arise during a merge
git merge --abort
Executing git merge with the --abort option will exit from the merge process and return the branch to the state before the merge began.
git reset
Git reset can be used during a merge conflict to reset conflicted files to a know good state
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.
After updating to the latest Windows Git (2.5.0 from 1.6.2) I find I'm unable to rebase a branch:
C:\core\guidewire\Dev\2.4>git checkout fhcf-assumptiondate && git rebase master
Previous HEAD position was d032e17... Merge branch 'de8041'
Switched to branch 'fhcf-assumptiondate'
First, rewinding head to replay your work on top of it...
fatal: C:\Program Files\Git\mingw64/libexec/git-core\git-am cannot be used without a working tree.
Comments on this question hint at a Git installation conflict, but the old version is entirely removed by now, including a lingering DLL and checking for stale environment vars.
Looking inside the git scripts, I find that the error message is coming from a test in git-sh-setup that uses git rev-parse --is-inside-work-tree. Consulting rev-parse directly shows that it seems to not understand that I really am inside the working copy:
C:\core\guidewire\Dev\2.4>dir .git
Volume in drive C is System (Local)
Volume Serial Number is D4EC-4ED4
Directory of C:\core\guidewire\Dev\2.4
08/04/2015 21:16 27 .git
1 File(s) 27 bytes
0 Dir(s) 155,451,965,440 bytes free
C:\core\guidewire\Dev\2.4>git rev-parse --is-inside-work-tree
false
...Except some commands are able to correctly tell the difference:
C:\core\guidewire\Dev\2.4>git status
HEAD detached from refs/heads/fhcf-assumptiondate
nothing to commit, working directory clean
C:\core\guidewire\Dev\2.4>cd ..
C:\core\guidewire\Dev>git status
fatal: Not a git repository (or any of the parent directories): .git
What is making Git confused about whether I'm in the right directory or not?
Possible points of interest:
Repo was created by the previous installation.
1.6.2 was an msys build of Git. 2.5.0 is MinGW.
The repo was cloned with --separate-git-dir.
checkout, status, add, commit and possibly others all have worked without issue since the upgrade.
A clone of the broken repository exhibits correct behavior; 'in' or 'out' of the working tree are detected correctly.
To continue using an existing (1.6.x-created) repository after upgrading to Windows Git 2.5, update the repo's gitconfig:
[core]
worktree = c:/core/guidewire/Dev/2.4
to
[core]
worktree = C:/core/guidewire/Dev/2.4
The new Git installation either obtains paths differently from the old, or is no longer case-insensitive about paths. Therefore the existing repo working tree location becomes wrong since no folder under c:\core\guidewire\Dev\2.4 will have a prefix of C:\core\guidewire\Dev\2.4. Git source for the current version shows no sign of case-insensitivity, so the msys fork may have modified the path-checking function, or case-smashed all paths prior to comparison.
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 have spent a great deal of time since I first started using Git struggling with files being reported as changed when they hadn't been touched, and core.filemode = false resolved those issues... but today I have the reverse problem. (Unless otherwise specified, I'm doing this from Git Bash (1.7.10.msysgit.1) in Windows 7.)
The situation:
On my master branch, I did git pull upstream master to pull the latest changes - this said everything was up to date (I double-checked and the last commit is the same on my local master, my origin fork and the upstream Github repo so I'm reasonably certain this is correct)
I amended an existing file. The diff in TortoiseGit 1.8.0.0 shows the changes, though its overlay still shows the directory as clean. Odd. git status is... still clean. Very odd.
I delete a file: rm Readme.md. File disappears. git status is still clean. Clearly, git isn't actually tracking my files anymore.
(For the record, setting core.filemode = true and then running git status just gave me nonsense about files whose mode changed at some point between my Windows system and Github, but still didn't list the deleted or the truly modified files)
I'm missing something here and I hope someone can tell me what it is! I've done dozens of commits from this machine to that same repository via my fork on Github so I'm reasonably certain this environment works and I generally know what I'm doing, but clearly something has changed that I can't put my finger on right now.
Edit, as requested, my Git workflow as followed in Bash (didn't bother checking out a new branch as the problem occurs in master anyway):
Emma Burrows#PC ~/Documents/Dropbox/gitproject (test)
$ git checkout master
Switched to branch 'master'
Emma Burrows#PC ~/Documents/Dropbox/gitproject (master)
$ git status
# On branch master
nothing to commit (working directory clean)
Emma Burrows#PC ~/Documents/Dropbox/gitproject (master)
$ git pull upstream master
From git://github.com/company/gitproject
* branch master -> FETCH_HEAD
Already up-to-date.
Emma Burrows#PC ~/Documents/Dropbox/gitproject (master)
$ rm Readme.md
Emma Burrows#PC ~/Documents/Dropbox/gitproject (master)
$ git status
# On branch master
nothing to commit (working directory clean)
Readme.md is a tracked file present in both my forked repo on Github and in the original upstream repo. I hope that helps?
NEW EDIT I've moved the folder out of Dropbox to a local folder on a local drive, but the problem remains the same. The .git folder must be poked. I was hoping to find out what was wrong with it though.
Thank you to everyone who tried to help. The problem persisted after I moved the whole folder, including .git folder into another location on my local hard drive. I can only assume that two copies of the repo on different machines had tried to sync the git folder at once and resulted in a broken local repo. I ended up recloning the folder (out of Dropbox for now) and everything is working normally again.