3

I'm getting an error when cloning a bitbucket-hosted repository to my computer.

When I enter in git bash:

git clone https://myusername@bitbucket.org/groupname/repositoryname.git

I get the message

Cloning into 'repositoryname'..

fatal: bad config line 1 in file U://.../repositoryname/.git/config

Unlink of file 'repositoryname/.git/config' failed.
Should I try again? (y/n)

The destination folder contains a .git subfolder, which itself contains the file config, along with a hooks subfolder containing various files.
The config file has the following contents:

[core]
repositoryformatversion = 0
filemode = false

Trying again by hitting y accomplishes nothing.

I am aware of a similar question asked earlier: Bad git config file .git/config, but that had to do with a repository that was being worked on.
This is a problem with even getting started, so I'm at a loss to see what to do.

In case my .gitconfig file is considered as a possible source of the error, here its contents:

[user]
name = ...
email = ...
Giulio Caccin
  • 2,962
  • 6
  • 36
  • 57
RAC
  • 31
  • 1
  • 3
  • Check the encoding of the config file? Maybe you have the wrong kind of line endings? – evolutionxbox Dec 11 '17 at 09:56
  • 1
    The formatting looks wrong in all your examples, there should be newlines where you have runs of whitespace – tripleee Dec 11 '17 at 10:08
  • The formatting seems to be a side effect of stackoverflow's text editor, which seems to ignore line breaks in quote mode. I will try to edit it to make it more readable. – RAC Dec 11 '17 at 15:19
  • With respect to the encoding of the config file, I don't know what it should look like so I don't know how to check this or fix it; it is automatically generated when I try to clone. – RAC Dec 11 '17 at 15:19
  • The "unlink ... failed" part of the message is particularly suspicious-looking. `git clone` normally creates a *new* repository in a *newly created* empty directory, and then populates that directory with files, which Git has full control over. No other process in the system should be messing with those files. Git should therefore be able to *remove* any of those files as well. This all suggests that you have some other process that is modifying Git's data *while Git tries to write it.* – torek Dec 11 '17 at 16:00
  • What is `U:`? Is this some file share or other oddly mounted drive? – Edward Thomson Dec 11 '17 at 16:34
  • 1
    U: is a network drive. It turns out that I can clone without problem to my local disk C:. This is not a perfect solution because I would prefer to work on U:, but is clearly better than nothing! What if anything can I do to try and diagnose what has gone wrong with my U: drive? – RAC Dec 12 '17 at 09:49

1 Answers1

3

Please check if you are cloning on a network drive, it is probably not working because of that.

If you can, please just switch to local machine.

If you really need to clone on a network drive please check if the problem is caused by hardlinks by using the --no-hardlinks option:

git clone --no-hardlinks /path/to/your/repository

NB: usually this happens if your HOMEDRIVE / HOMESHARE environmental variables are set on a network drive and you clone for the first time.

Giulio Caccin
  • 2,962
  • 6
  • 36
  • 57
  • I've added this answer as a thanks to *RAC* user that pointed out and solved this problem for me, but he did not login in the last year. – Giulio Caccin Jan 07 '20 at 15:12
  • 1
    You save my life. I have spent the entire day trying to find out why. I have exactly the same issue as you. – Kevin Oct 25 '21 at 10:54