0

I asked this on a Microsoft forum, and the answer said I should ask it on this other Microsoft forum. That forum said I should ask the automated MS thing or come here. In short, I don't expect MS to help me with this. Anyway...

I'm in process of migrating some repos from Mercurial to Git (using fast-export). The actual transition is fine: the history is fully intact and the branches are all there.

However, I can't push some of these new repos to MS Azure. I'll cover the largest (and most critical) one here. It gives the following error.

$ git push -u origin --all
Enumerating objects: 138051, done.
Counting objects: 100% (138051/138051), done.
Delta compression using up to 12 threads
Compressing objects: 100% (43406/43406), done.
Writing objects: 100% (138051/138051), 202.73 MiB | 76.12 MiB/s, done.
Total 138051 (delta 94104), reused 137561 (delta 93696), pack-reused 0
error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly
Everything up-to-date

The repository is just over 1 GB, and the packfile is most of that. To avoid a massive file keeping me from pushing, I used git repack and broke it up into 10 ~100MB files. I don't have a max push size set on Azure, and no single file in this repo exceeds 100 MB.

I've read numerous posts on several websites, but their suggestions haven't helped. My config file is set up as follows. (Our main branch is called "Production.")

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
    symlinks = false
    ignoreCase = false
[branch "Production"]
    remote = origin
    merge = refs/heads/Production
[http]
    postBuffer = 2147483648
[remote "origin"]
    url = ********
    fetch = +refs/heads/*:refs/remotes/origin/*

I can push to GitHub without any problems, even if I leave the packfile as a single 1GB file. I can also import the repo from GitHub to Azure (still with the 1 GB packfile), but my boss wants to know if there's a way to eliminate that intermediary step.

I'm running Windows 11, and I've tried to push from the command line, PowerShell, Git Bash, and Git Extensions, all with the same result. I even tried pushing from Windows 11's Linux VM, but I had no luck.

If I'm doing something wrong, I'd love to know what it is and how to do it right.

Luke in IT
  • 11
  • 1
  • 413 = payload too large. 1 GB is not too big for Git, so this must be some sort of Azure limitation. See also [Azure App Service Returning 413 Payload Too Large on Long POST Request](https://stackoverflow.com/q/70071422/1256452) for instance. Note that `git push` does its own pack-building; you can `git push` some commits at a time, rather than fiddling with `git repack` (which has no effect on individual `git push` commands anyway). – torek May 25 '22 at 09:21
  • Interesting. The thing that strikes me as odd is the fact that I can import from GitHub without any problems. Is that more of a pull than a push? – Luke in IT May 25 '22 at 14:57
  • If you initiate it from Azure, yes. Note that some Git builds have issues at 2 and 4 GB boundaries (due to 32-bit integers where 2147483647 is positive but add 1 and you get -2147483648, the most negative number, or 32-bit unsigned integers where 0xFFFFFFFF + 1 = 0) but 1 GB doesn't bump into these two. Git uses 64-bit integers for sizes on systems where that's allowed, so one can theoretically go well into the terabyte range (and then one starts to bump into address space limits on some hardware). – torek May 26 '22 at 00:32
  • Thanks! I ended up getting another solution from a co-worker. Pushing over SSH instead of HTTPS didn't have these problems. – Luke in IT May 31 '22 at 21:33
  • Curious (and interesting) - that suggests that there's a 32-bit size limit somewhere in the https push code path on Windows-11 (perhaps in the Windows version of libcurl). – torek Jun 01 '22 at 01:39

1 Answers1

1

A co-worker recommended pushing over SSH instead of HTTPS, and it worked just fine! Hopefully anyone else who runs into this same problem will benefit from this solution as well.

Luke in IT
  • 11
  • 1