CODEWITHSUNDEEP
git
David Parks
David Parks

Reputation: 32051

Git error during clone: error: Untracked working tree file <file> would be overwritten by merge

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'

Upvotes: 1

Views: 1164

Answers (1)

torek
torek

Reputation: 487755

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.

Upvotes: 1

Related Questions