I had a situation where I had a pair of trees, and a git daemon
setup, such that in the client tree if I say
   git fetch origin
git-fetch exits with status 1 but prints nothing to stderr.

I straced and found a missing object complaint about the object which
was refs/stash (from `git stash') on the server.  Making a branch on
the server referring to that object fixed the problem.

I don't know why the error message got thrown away.

The bug report `git fetch failure when remote has stash' is about the
failure.  After filing this report I will clone it to make a new bug
report about the discarded error message, which I will title `git
fetch discarded error message'.


In more detail:


The server is drall.  It has a bare tree.  Here is its config:

  [core]
	  repositoryformatversion = 0
	  filemode = true
	  bare = true
  [remote "origin"]
	  fetch = +refs/*:refs/*
	  mirror = true
	  url = git://mariner.uk.xensource.com/xen.git

And:

  git-cache@drall:/var/cache/git-cache-proxy/git:,,mariner.uk.xensource.com,xen.git\.git$ git fetch origin
  git-cache@drall:/var/cache/git-cache-proxy/git:,,mariner.uk.xensource.com,xen.git\.git$ echo $?

(I hope the unusual name of the client cwd is not relevant.)


I straced the fetch (strace -s500 -ffot git fetch origin) and saw two
processes, of which the child did this:

  write(2, "fatal: bad object 9381f1cbf6e434f279a5b7a12ea01c48b45b3bfb\n", 59) = 59

Searching for that hash in the strace logs showed the parent doing
this:

  read(4, "0038", 4)                      = 4
  read(4, "9381f1cbf6e434f279a5b7a12ea01c48b45b3bfb refs/stash\n", 52) = 52
  ...
  write(7, "9381f1cbf6e434f279a5b7a12ea01c48b45b3bfb\n", 41) = 41

I think that is the protocol stream from the server, and a pipe to the
child, respectively.


The server is also running the same version of git.  It has a git
daemon run from inetd.conf:

  9418 stream tcp nowait nobody /usr/lib/git-core/git-daemon git-daemon --base-path=/u/iwj/public-git --export-all --inetd

/u/iwj/public-git/xen.git is a symlink to /u/iwj/work/xen.git/.git and
/u/iwj/work/xen.git is my main xen.git working tree.

At the time of the failure, the object
9381f1cbf6e434f279a5b7a12ea01c48b45b3bfb was indeed stash@{0}.

On a hunch I created a dummy branch on the server:

  mariner:xen.git> git-branch -D t
  Deleted branch t (was f31cbb2).
  mariner:xen.git> git-branch t 9381f1cbf6e434f279a5b7a12ea01c48b45b3bfb
  mariner:xen.git>

After that, the git fetch succeeded:

  git-cache@drall:/var/cache/git-cache-proxy/git:,,mariner.uk.xensource.com,xen.git\.git$ git fetch
  remote: Counting objects: 10, done.
  remote: Compressing objects: 100% (6/6), done.
  remote: Total 6 (delta 5), reused 0 (delta 0)
  Unpacking objects: 100% (6/6), done.
  From git://mariner.uk.xensource.com/xen
   + f31cbb2...9381f1c t          -> t  (forced update)
   * [new ref]         refs/stash -> refs/stash
  git-cache@drall:/var/cache/git-cache-proxy/git:,,mariner.uk.xensource.com,xen.git\.git$


Both client and server are running wheezy's git.  The straces from the
failing run are attached.

Ian.