Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

[Jeff King <peff@peff.net>]

On Wed, Sep 13, 2017 at 03:38:52PM +0200, demerphq wrote:

> 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.

As a side note, I'm surprised that commands work at all when your
.git/config is empty. I'd expect check_respository_format() to complain
that you are not in a repository.  Looks like it is due to this block:

  452		 /*
  453		  * For historical use of check_repository_format() in git-init,
  454		  * we treat a missing config as a silent "ok", even when nongit_ok
  455		  * is unset.
  456		  */
  457		if (candidate.version < 0)
  458			return 0;

> > 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...

You're welcome to read over the function to double-check, but I just
looked it over and couldn't find any unchecked writes.

> > 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?

If you think you can reproduce, the output of "strace" on a failing
invocation would be very interesting.

-Peff