On 13 September 2017 at 14:34, Jeff King <peff@xxxxxxxx> wrote: > On Wed, Sep 13, 2017 at 01:59:17PM +0200, demerphq wrote: > >> After being away for a while I saw the following message in one of my git repos: >> >> $ git status >> On branch yves/xxx >> Your branch is based on 'origin/yves/xxx', but the upstream is gone. >> (use "git branch --unset-upstream" to fixup) >> >> nothing to commit, working tree clean >> $ git branch --unset-upstream >> fatal: could not unset 'branch.yves/simple_projection.merge' > > Hrm. I wonder what caused this failure. The error would be in > git_config_set_multivar_in_file_gently(). Most errors there produce > another error message before hitting the die(). In fact, the only case I > see where it would not produce another message is if it found nothing to > unset (but in that case, "branch" would never have called the function > in the first place). I just double checked the terminal history and this is all i saw: $ git status On branch yves/xxx Your branch is based on 'origin/yves/xxx', but the upstream is gone. (use "git branch --unset-upstream" to fixup) nothing to commit, working tree clean $ git branch --unset-upstream fatal: could not unset 'branch.yves/xxx.merge' $ git status On branch yves/xxx nothing to commit, working tree clean $ git fetch fatal: No remote repository specified. Please, specify either a URL or a remote name from which new revisions should be fetched. >> At this point my .git/config file was empty, and all of my config was lost. >> >> I assume that things that rewrite .git/config do not check for a >> successful write before deleting the old version of the file. > > No, it writes the new content to "config.lock" and then renames it into > place. > All of the write() calls to the temporary file are checked. I was going to say that perhaps the write was not checked... But if you are confident they are then... >The > old data is copied over after having been ready by mmap (which is also > error-checked). > > Given that your output is consistent with it failing to find the key, > and that the result is an empty file, it sounds like somehow the mmap'd > input appeared empty (but neither open nor fstat nor mmap returned an > error). You're not on any kind of exotic filesystem, are you? I don't think so, but I don't know. Is there a command I can run to check? BTW, with a bit of faffing I can probably recreate this problem. Should I try? Is there something I could do during recreation that would help? cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
