Junio is absolutely right. I wasn’t trying to commit that file directly. The error comes up when I want to change the config via git config or when I clone the repo. I also know that a shared folder is not a very friendly environment, but it is the best solution for our situation here. We recognized the error first time in the beginning of july, so the change done in june 30 seems to be a reason. I will stay up to date and try it with newer git versions. Mit freundlichen Grüßen Peter Hüfner ......................................................... e·confirm GmbH .. Travel.Software.Training.Consulting Geschäftsführer: Roman Borch und Michael Posthoff HRB 35653B Steuernummer 37/211/10880 10119 Berlin Linienstr. 214 Tel. +49 (0) 30 28 00 28 24 Fax. +49 (0) 30 28 00 28 28 www.e-confirm.de ................................................................................................. > Am 16.07.2015 um 18:41 schrieb Junio C Hamano <gitster@xxxxxxxxx>: > > Stefan Beller <sbeller@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html