简体   繁体   中英

Pushing local Git repo with LFS enabled to an empty Azure Devops fails

On a mission to move our SVN repo to a Git repo and am almost there but falling at the final hurdle.

Locally I have:

  • Created a empty git repo, via git svn init

  • Enabled LFS and configured it to to track a bunch of different files.

  • Migrated my SVN repo, via git svn fetch

  • Tidied up some superfluous tags and ended up with a single "main" branch and a bunch of tags.

  • I add the remote origin to a new empty Azure Devops repo, via git remote add origin [azure git URL]

  • I run the following command:

    git push origin -all

I get the following message and ultimately error, with nothing showing in AzDevOps:

 Locking support detected on remote "origin". Consider enabling it with: $ git config lfs.https://[redacted]/info/lfs.locksverify true LFS: Client error: https://[redacted]/info/lfs/objects/bd2cc3927bf072a20412a03bfc58570b8d7c7eaad4737b6c70717baa0c0b697e from HTTP 413 Uploading LFS objects: 100% (684/685), 232 MB | 7.1 MB/s, done. error: failed to push some refs to 'https://[redacted]'

Just in case I ran suggested command to add the locking config and then try again. I get the same error but without the locking suggestion.

Any ideas how to debug whats wrong? My Bingle skills have abandoned me and can't seem to find much that relates to my scenario.

Azure DevOps uses IIS, which has some unpleasant problems with HTTP/2. The gory details are mentioned in the Git LFS issue tracker , but essentially the fact that you're getting a 413 Request Too Large means that Azure DevOps can't gracefully handle large files over HTTP/2. This isn't the fault of Git LFS, but instead a configuration problem with the way Azure DevOps has set up their LFS server. Other hosting sites don't have this problem.

As a workaround, you can run git config http.version HTTP/1.1 , which should allow you to push the data properly. Note that each user will need to configure this when pushing a file over about 128 MB until Azure DevOps fixes this problem.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM