1

I just deleted my git repo and am cloning it anew. I can't figure out how I might encounter the error below.

I use the same repo on another machine (as do dozens of other people). I tried following the git checkout -f HEAD suggested. It syncs up a lot of files that were missed during hte clone, but it still shows a few dozen modified and missing files somehow. I completely removed the old directory. And df -h shows available disk space.

$ git clone [email protected]:myrepo/src.git Cloning into 'src'... remote: Counting objects: 83096, done. remote: Compressing objects: 100% (309/309), done. remote: Total 83096 (delta 351), reused 385 (delta 228), pack-reused 82556 Receiving objects: 100% (83096/83096), 785.59 MiB | 22.16 MiB/s, done. Resolving deltas: 100% (41943/41943), done. Checking connectivity... done. error: Untracked working tree file 'common/ml/.pylintrc' would be overwritten by merge. fatal: unable to checkout working tree warning: Clone succeeded, but checkout failed. You can inspect what was checked out with 'git status' and retry the checkout with 'git checkout -f HEAD'
Improve this question
1
  • It seems you have a local file which is untracked, while it is tracked in the remote repo, thus a weird conflict. Could you try : git add -A ; git stash this will track all your local files, stash your changes, then git pull to retrieve remote changes ? Commented Apr 9, 2018 at 21:57

1 Answer 1

Reset to default
1

First, note that git clone is essentially a multi-step process consisting of:

  1. Make a new empty directory (or use an existing empty directory, if instructed). Do all the work in this new empty directory.

  2. Create an empty Git repository in this empty directory: git init.

  3. Add a remote, named origin by default, using the URL you gave. Do any necessary configuration (with git config or git remote add) to set this up. Depending on configuration options you specified, other configuration may take place at this point as well.

  4. Run git fetch origin (or whatever name you told Git to use instead of origin) to bring in all the commits from the URL you gave.

  5. Run git checkout on some branch name, probably master, to create a local branch named master pointing to the same commit as origin/master.

It's this final step that is failing. Now, we know from the above that src should be a new, empty directory. This means it literally cannot have an existing file named common/ml/.pylintrc.

What could happen, though, is that the commit being checked out could have a file named common/ml/.pylintrc in it, which this git checkout puts into the work-tree. Then, earlier or later, the commit being checked out could have another file named, e.g., COMMON/ML/.pylintrc or common/ML/.pylintrc or some such—basically the same name except for case.

If the people using the repository you're cloning are using Linux, which has case-sensitive file systems by default, these two names—common/ml/.pylintrc and common/ML/.pylintrc or whatever they are—name two different files, and all is well.

If you, however, are on a Mac or Windows system and are using a file system that is case-insensitive by default, these two different file names name the same file. So your Git goes to overwrite one file with the other file, and realizes that this is bad news and aborts the git checkout step.

The easiest way to fix this sort of problem is to run Linux (e.g., in a VM on your Mac). Clone the repository there, fix things so that there are not multiple file names that differ only in case, commit, get the fix adopted upstream, and now you can work on your Mac or Windows system that treats these two different file names as one underlying file.

It is theoretically possible to fix this other ways, but they are definitely harder and I have not attempted them.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

Great answer! Thanks for that explanation, it's tremendously helpful. And we have had Windows/Linux issues in git before. However, I'm the linux user in this case... But I'm digging to see if I can find some way this might apply. That file is maintained by a windows user.
Interesting! I wonder if there's a Windows UTF-16 encoding issue. If you're familiar with Git's internals, look at the tree object for the commit being checked out and find the sub-trees that represent common and ml (with either case).
Ugg! I get the dunce cap today. I had a background process rsyncing some files, and, as murphy's law states it will, the sync had such perfect timing that it slipped just under my nose over a half dozen times that I deleted/cloned. Your answer was very illuminating though and I learned a lot about git along the way and helped me know what I didn't know, so I really appreciate that.
Ouch, I did not even think of rogue background processes creating files! (I was wondering about the all-lowercase here, since uppercase names will come before lowercase ones in Git internal sort order, so that the complaint in general should be about files with uppercase in their names, if it's a case issue.)

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.