4

I have empty private repository on GitHub I can normally access from the web.

When I make attempt to push some history I already did locally, I'm getting:

fatal: protocol error: unexpected capabilities^{}

Googling indicates in the past it meant server doesn't support SHA256, but that was 9 years ago. What could go wrong today?

How to diagnose the problem?

What's the remedy for it?

I'm using git version 2.34.1 from Ubuntu 22.04.

Edit: Following @VonC answer I upgraded git to 2.42.0. And now the message changed to:

fatal: the receiving end does not support this repository's hash algorithm

which absolutely doesn't help how to fix the problem with the local repo. Hashes in the log are 64 characters long.

Michał Fita
  • 1,183
  • 1
  • 7
  • 24

2 Answers2

4

I have seen that error message when using Eclipse/JGit, as I explained in JGit: BundleWriter Error when including Refs.

This patch explains:

The cause is that, since v3.1.0.201309270735-rc1~22 (Advertise capabilities with no refs in upload service., 2013-08-08), JGit's ref advertisement includes a ref named capabilities^{} to advertise its capabilities on, while git's ref advertisement is empty in this case. This allows the client to learn about the server's capabilities and is needed, for example, for fetch-by-sha1 to work when no refs are advertised.

This also affects "ls-remote". For example, against an empty repository served by JGit:

$ git ls-remote git://localhost/tmp/empty
0000000000000000000000000000000000000000        capabilities^{}

Git advertises the same capabilities^{} ref in its ref advertisement for push, but since it never did so for fetch, the client didn't need to handle this case.

Check first if the push was done from Eclipse (which would not use a system Git)
And check if upgrading Git (command-line) is enough.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • No, I haven't used Eclipse. It's possible the first commit was done in VSCode. Look at my edit what changed after upgrade of `git` to 2.42.0. I still need to treat this repo to get a remedy as Google in this new case is absolutely helpless. Thanks. – Michał Fita Aug 26 '23 at 20:37
  • @MichałFita Can you enable [`TRACE2`](https://git-scm.com/docs/api-trace2) in case it has some clues? (`GIT_TRACE2` or `GIT_TRACE2_EVENT`) – VonC Aug 26 '23 at 21:18
  • UX of this problem is awful - I answered myself in the end. GitHub doesn't accept pushes from repos with format version 1 and SHA256. In 2023... awesome, just awesome. – Michał Fita Aug 26 '23 at 21:47
  • @MichałFita Good catch, upvoted. I have written about SHA256 [here](https://stackoverflow.com/a/47838703/6309) and [here](https://stackoverflow.com/a/60088126/6309). Git 2.43 [removed its experimental status](https://stackoverflow.com/a/76879153/6309). – VonC Aug 26 '23 at 21:58
1

The problems seems to be that the error (in new git):

fatal: the receiving end does not support this repository's hash algorithm

is caused by the simple fact GitHub in 2023 still doesn't support repository version format 1 with SHA256 commits (Sadly true about GitLab either).

When I rewrite history by format-patch of each commit and git am them on fresh repository with format version 0 (I had to recreate tags as well), then I managed to push.

Now, how my repository has been created as version 1 originally I don't know/remeber - I think it was bare git init, but maybe it was something else (possibilities are cargo and VSCode).

You have been warned. Hopefully this answer (valid at the day of writing) would help anyone else Googling for this problem.

Michał Fita
  • 1,183
  • 1
  • 7
  • 24