Stefan Beller <[email protected]> writes:
>>> A few weeks ago we weren’t able to clone and get an error: could
>> not commit /vagrant/.git/config file. Manually we were able to
>> change that file and also the clone command works outside the shared
>> folder.
>>
>> Why are you trying to commit a file inside the .git dir? Files in that
>> dir should not be commited (and I'm pretty sure there was a patch about
>> this a while ago). The .git/config file for example is local to each git
>> repo and should not be commited.
>
> Actually it is considered a security risk, see
> http://article.gmane.org/gmane.linux.kernel/1853266
I do not think Peter meant to "git add .git/config && git commit" by
referring to the 'could not commit config file' error message he
saw; you two are going in a wrong direction.
$ git grep 'could not commit'
config.c: error("could not commit config file %s", config_filename);
I do share Fredrik's suspicion that the virtual filesystem the
Ubuntu guest is trying to write to is at fault, but I never used
"vagrant shared", and I do not know in what specific way their
filesystem is not behaving as we expect.
Applying 7a64592c (config.c: fix writing config files on Windows
network shares, 2015-06-30) might be an interesting thing to try.
Some filesystems do not want to rename a file that has mmaped region
still active, which is my blind guess.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
