CODEWITHSUNDEEP
git
TheMeaningfulEngineer
TheMeaningfulEngineer

Reputation: 16359

Diagnosis of git fetch/pull error

The question about this problem has been asked several times already:

I have the same error, but am looking for a valid diagnosis method to conclude that its a network problem or git (don't need to fix it afterwards).

Problem description

Git version that is used is 1.8.4.msysgit.0

  1. Bare repo hosted with git daemon on one of the computers

    git daemon --verbose --export-all --enable=receive-pack --base-path="C:\path\to\git_remotes"

  2. Other computers use that repo via git protocol

  3. People on other computers (all in same subnet) can sometimes do successful clone/pull/fetch/push. Other times they get the following error

enter image description here

Their actions are always detected in the shell where git daemon is started, even on failure. A local clone/pull/fetch/push from the daemon works always

Update: git fsck

On the local repo (one that always works). There is one dangling blob. On the bare repo (thats on the same computer as the local repo). No dangling blobs or commits.

On other non-bare repos (on other computer created by cloning the bare repo):

They both don't function.

What is the meaning of the error above and can it be diagnosed with wireshark (it mentions some pack headers) to see if it's a network or a git error?

Upvotes: 1

Views: 824

Answers (2)

VonC
VonC

Reputation: 1324947

Note: in addition of GIT_TRACE=2 GIT_TRACE_PACKET=2 , git fetch itself will be a bit more verbose in git 2.8 (March 2016)

See commit f3ee9ca (28 Jan 2016) by Eric Wong (ele828).
(Merged by Junio C Hamano -- gitster -- in commit fbf4bdf, 10 Feb 2016)

pass transport verbosity down to git_connect

There were a few "now I am doing this thing" progress messages in the TCP connection code that can be triggered by setting a verbose option internally in the code, but "git fetch -v" and friends never passed the verbose option down to that codepath.

So you can add git fetch -v to the list of debugging option.

In addition, with Git 2.34 (Q4 2021), ls-remote is better traced:

See commit f58c746 (23 Aug 2021) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit 63ddde6, 08 Sep 2021)

ls-remote: set packet_trace_identity()

Signed-off-by: Ævar Arnfjörð Bjarmason

Set packet_trace_identity() for ls-remote.
This replaces the generic "git" identity in GIT_TRACE_PACKET=<file> traces to "ls-remote", e.g.:

[...] packet:  upload-pack> version 2
[...] packet:  upload-pack> agent=git/2.32.0-dev
[...] packet:    ls-remote< version 2
[...] packet:    ls-remote< agent=git/2.32.0-dev

Where in an "git ls-remote file://<path>"(man) dialog, ">" is the sender (or "to the server") and "<" is the recipient (or "received by the client").

Upvotes: 1

John Szakmeister
John Szakmeister

Reputation: 47032

There are several ways to go about debugging the problem. Since it's claiming the pack header is wrong, it seems like it's probably a server-side issue. Assuming you're running under a unix-style operating system, you can try running:

GIT_TRACE=2 git fetch

To see some more information about what is happening under the hood. It may give a better indication where things are failing. However, to see actual data transfers, you should try:

GIT_TRACE=2 GIT_TRACE_PACKET=2 git fetch

That will dump what's being transmitted on the wire. This would be the place to identify anything strange being passed between the client and the server.

All of that said, there was a bug fixed where git prune (which is executed automatically when repacking) would accidentally print to stdout and break the pack protocol. This was fixed in git 1.7.12.1, so the answer may be to simply upgrade Git.

If you're running Ubuntu on the server, you can add the git-core PPA and get the latest stable version from there. Directions on how to do that are on the website.

Upvotes: 3

Related Questions