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.
Related
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
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.
This morning my Windows 10 crashed and rebooted once I lifted my laptop's screen. No special activity was progressing, so I don't think there was significant disk activity.
However one of my main Git repos crashed after that reset. Here is what I tried:
$ git status
fatal: Not a git repository (or any of the parent directories): .git
$ git init
Reinitialized existing Git repository in ....../.git/
$ git status
fatal: Not a git repository (or any of the parent directories): .git
Loop
I don't think I have unpushed commits, so wiping and cloning from remote should work.
Still, can I ask what to do to recover an existing Git repository (.git directory still exists, chkdsk reports OK) in such cases?
[Add] read this but did not apply to my case (I can't restore the repo)
As kabanus said in a comment, you should definitely save whatever you can before proceeding (and/or use some other existing clone as a backup).
When Git complains about this, though, it often means that the file .git/HEAD has gone missing. If you create a new HEAD file with contents: ref: refs/heads/master, Git may be able to recover everything.
Since HEAD is the most active file in the repository, it's the one most likely to be clobbered by an OS error or power failure. It's also a critical file when it comes to whether Git believes a .git directory is a repository: if the directory contains a file named HEAD (along with a few other key items), it is a repository; if not, it is not a repository.
I had multiple branches corrupt due to OS error (bloody windows sleep function!!). So I had to manually do the following:
.git/HEAD (set content to ref: refs/heads/master)
$> git branch -v (this will tell you all the corrupt branches)
.git/logs/HEAD (Read the file for last checksum of the commits and merge of corrupt branches)
.git/refs/heads/{corrupt branch file} (change the checksum to the last working checksum from the log file.
merge the branches again as per need.
Another workaround for this, Solved for me while OS crashed on GIT MERGE operation
Get the working HEAD,FETCH_HEAD files under .git/ directory(of your project) from some other contributor
Replace the existing HEAD,FETCH_HEAD files with new ones(taken from other contributor).
Delete the INDEX under .git/ directory.
Then Do a git pull.
In my case, the HEAD file was indeed corrupted due to a system crash.
I just cloned the repo again into a new folder, switched to the branch I was in, then replaced the .git folder with the one I just created from the clone.
From there, it was like nothing happened.
In my case, The ownership of the repo was mismatched after OS reset.
I tried #raheel-hasan's instructions, after entering git branch -v command I got a suggestion.
git config --global --add safe.directory 'direactory path' this command solved the issue :)
(Use powershell to run this command)
You shoult reload your IDE or code editor after running this command.
First, let me tell you that I have already checked all the similar threads and searched google to find what the problem may be, but no success. My problem is that I'm trying to use sparse checkout in git, but I get this error:
error: Sparse checkout leaves no entry on working directory
I have this 60GB repository, which I need to clone. I need only a part of it, so to save a disk space I wanted to use sparse checkout. This is what I do:
mkdir repoDir
git init repoDir
cd repoDir
git remote add origin <repo url>
git config core.sparsecheckout true
echo "some/dir/" >> .git/info/sparse-checkout
git pull --depth=1 origin master
Note I add the remote without -f flag, so nothing is fetched.
The result:
error: Sparse checkout leaves no entry on working directory
I tried several things:
Instead of initialising new repo and adding the remote manually, I did git clone --no-checkout and then set up the sparse checkout. This didn't help as my git status showed as if I deleted all the files in my repo. The git pull origin master command results in the same error.
Tried all possible combination of paths in step 6, with preceding slashes, slashes after the path, stars, spaces between path and > or >>. Btw I'm confused what is the correct format here, from the comments on SO I see mutually exclusive ways of formatting this.
Tried to make sure my .git/info/sparse-checkout is ASCII, and has proper line endings as found here. This is probably only problematic on Windows, but I just checked this anyway.
My git version: git version 1.9.3 (Apple Git-50)
OSX Yosemite 10.10.2 (14C109)
It turns out that "some/dir/" was wrong, since I didn't have the repository I didn't know it's real structure. I was able to browse it through web interface but I just discovered the folders don't correspond exactly to the real repository folder structure.
Lesson for the future: make sure you know the folder structure before creating sparse-checkout file.
The sequence of operations I wanted to follow is similar, namely the one suggested in this other post https://stackoverflow.com/a/13738951/5459638. I get the error message
error: Sparse checkout leaves no entry on working directory
when launching git pull <remote> <branch> with branch being master.
As #lawicko said, in the project webpage I can click my way to the subdirectory to be cloned and copy the URL of that page; ctrl+L ctrl+C makes doing this nice and quick. This URL has the form
https://gitlab.com/<username>/<project>/tree/master/<subdir>/<subdir>
The part that my sparse-checkout file accepts is the children of master
<subdir>/<subdir>/
with the trailing slash.
As an alternative to the same aim, there is another path in the form <project>/<subdir>/<subdir> to the right of the drop-down menu for switching branches at the top of the webpage.
In this case, I would have copied and pasted the children of <project> plus the trailing slash.
And this path is not as easy to copy and paste as the URL is.
Note that if you are using sparse-checkout on windows, you may need to add core.protectNTFS false per https://github.com/git-for-windows/git/issues/2777
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.