Getting remote git commit log without local copy

The pack-objects (man git-pack-objects) died of signal 13 (broken pipe), because git was unable to inflate (uncompress) the object and it failed with error (error code -5 could mean out-of-mem or overwrite/overlap error).

Explanation

According to zlib manual, the errors are defined as follow:

#define Z_OK            0
#define Z_STREAM_END    1
#define Z_NEED_DICT     2
#define Z_ERRNO        (-1)
#define Z_STREAM_ERROR (-2)
#define Z_DATA_ERROR   (-3)
#define Z_MEM_ERROR    (-4)
#define Z_BUF_ERROR    (-5)
#define Z_VERSION_ERROR (-6)

where -5 means no progress is possible or if there was not enough room in the output buffer.

Z_BUF_ERROR if no progress is possible or if there was not enough room in the output buffer when Z_FINISH is used. Note that Z_BUF_ERROR is not fatal, and inflate() can be called again with more input and more output space to continue decompressing.

Here is what we can read in zlib FAQ:

Before making the call, make sure that avail_in and avail_out are not zero. When setting the parameter flush equal to Z_FINISH, also make sure that avail_out is big enough to allow processing all pending input. Note that a Z_BUF_ERROR is not fatal--another call to deflate() or inflate() can be made with more input or output space. A Z_BUF_ERROR may in fact be unavoidable depending on how the functions are used, since it is not possible to tell whether or not there is more output pending when strm.avail_out returns with zero. See zlib Usage Example for a heavily annotated example.

Solution

This may be related to few things:

• the object being pushed is too big so zlib is of memory, so you need more space in the output zlib buffer,

  In this case, try increasing http.postBuffer, e.g.

  git config http.postBuffer 134217728 # =~ 128MB
  

  Alternatively use bfg to strip larger blobs, e.g.

  java -jar bfg.jar --strip-blobs-bigger-than 100M some-big-repo.git
  

• your object is corrupted, so run git fsck --full and git gc

  Potential reason could be corrupted memory or storage device, so retry on clean repository or different computer.

• could be a git bug, since it shouldn't abort on Z_BUF_ERROR, but to provide more output space or more input, see: zLib inflate() hangs while uncompressing buffer

  You may report a git bug report to the mailing list.

• could be a gzip inflate issue it-self (e.g. Is this a bug in this gzip inflate method?)

• could be an old kernel bug (<= 2.6.32-rc4), so upgrade your kernel

  See: Bug#547503: git-core: "git clone" fails on armel

  The only possibly relevant kernel change I could find was commit 5a3a29f (ARM: 5691/1: fix cache aliasing issues between kmap() and kmap_atomic() with highmem, commit 7929eb9 upstream) from 2.6.31.1. So though I also have my doubts, we could be lucky.^msg00049

Other useful commands to consider:

• GIT_TRACE=1 git push origin
• git count-objects -Hv to check for excess of size limits

See also:

• Z_BUF_ERROR -5 while trying to decompress zlib data at SO
• zlib inflate returning a buffer error at SO

Here is failing relevant Git code (builtin/index-pack.c):

git_inflate_init(&stream);
stream.next_out = buf;
stream.avail_out = buf == fixed_buf ? sizeof(fixed_buf) : size;

do {
    unsigned char *last_out = stream.next_out;
    stream.next_in = fill(1);
    stream.avail_in = input_len;
    status = git_inflate(&stream, 0);
    use(input_len - stream.avail_in);
    if (sha1)
        git_SHA1_Update(&c, last_out, stream.next_out - last_out);
    if (buf == fixed_buf) {
        stream.next_out = buf;
        stream.avail_out = sizeof(fixed_buf);
    }
} while (status == Z_OK);
if (stream.total_out != size || status != Z_STREAM_END)
    bad_object(offset, _("inflate returned %d"), status);
git_inflate_end(&stream);

and git_inflate() from zlib.c

status = inflate(&strm->z,
         (strm->z.avail_in != strm->avail_in)
         ? 0 : flush);

As hinted in GitHub help:

1. Create a new repository on GitHub.

2. Open Git Bash.

3. Change the current working directory to your local project.

4. Initialize the local directory as a Git repository.

    $ git init
   

5. Add the files in your new local repository. This stages them for the first commit.

    $ git add .
   

6. Commit the files that you've staged in your local repository.

    $ git commit -m "First commit"
   

7. At the top of your GitHub repository's Quick Setup page, click to copy the remote repository URL.

8. In the Command prompt, add the URL for the remote repository where your local repository will be pushed.

    $ git remote add origin <remote repository URL>
    # Sets the new remote
    $ git remote -v
    # Verifies the new remote URL
   

9. Push the changes in your local repository to GitHub if there is a remote branch called master (or main if that's what you're using)

    $ git push origin master
   

   Otherwise you will have to name local branch first by

    $ git branch -m <new_name>
   

   and then push it to add a new branch called <new_name>

    $ git push origin -u <new_name>
   

If you still end up with errors like "Updates were rejected because the remote contains work that you do not have locally", this is normally because that the remote repo is recently created manually. Make sure you are not overwriting anything on the remote end before you force push local git folder to it using

$ git push origin -u -f <new_name>