How to copy a repository into a new (not fork) repo

[edgarbc]

Select Topic Area

Question

Body

I have an old_repo that I want to use as a source to copy into a new_repo. From https://docs.github.com/en/repositories/creating-and-managing-repositories/duplicating-a-repository

I created the NEW-REPOTORY in github, then

git clone --bare https://github.com/EXAMPLE-USER/OLD-REPOSITORY.git

cd OLD-REPOSITORY
git push --mirror https://github.com/EXAMPLE-USER/NEW-REPOSITORY.git

when I am doing the final push, I get:

Enumerating objects: 326711, done.
Counting objects: 100% (326711/326711), done.
Delta compression using up to 8 threads
Compressing objects: 100% (85701/85701), done.
Writing objects: 100% (326711/326711), 350.23 MiB | 1.43 MiB/s, done.
Total 326711 (delta 228546), reused 326711 (delta 228546), pack-reused 0
remote: Resolving deltas: 100% (228546/228546), done.
error: RPC failed; curl 18 Transferred a partial file
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly
Everything up-to-date

then from https://www.bstefanski.com/blog/how-to-resolve-git-fatal-the-remote-end-hung-up-unexpectedly, I increased the buffer:

git config http.postBuffer 2147483648

and I still get

Enumerating objects: 326711, done.
Counting objects: 100% (326711/326711), done.
Delta compression using up to 8 threads
Compressing objects: 100% (85701/85701), done.
Writing objects: 100% (326711/326711), 350.23 MiB | 293.72 MiB/s, done.
Total 326711 (delta 228546), reused 326711 (delta 228546), pack-reused 0
remote: Resolving deltas: 100% (228546/228546), done.
error: RPC failed; curl 18 Transferred a partial file
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly
Everything up-to-date

any ideas what is the problem?

[M677871]

Do it step by step from a terminal:

1. Clone the source repository as a mirror:

git clone --mirror https://github.com/EXAMPLE-USER/OLD-REPOSITORY.git

2. Go into the mirrored repository:

cd OLD-REPOSITORY.git

3. Point origin to the new repository:

git remote set-url origin https://github.com/EXAMPLE-USER/NEW-REPOSITORY.git

4. Push everything to the new repository:

git push --mirror

OR You can also send it as one block so they can copy everything at once:

git clone --mirror https://github.com/EXAMPLE-USER/OLD-REPOSITORY.git
cd OLD-REPOSITORY.git
git remote set-url origin https://github.com/EXAMPLE-USER/NEW-REPOSITORY.git
git push --mirror

[prajasus2308]

Practical fixes
Use --no-verify and smaller pushes
Instead of mirroring everything in one go, try splitting the push into smaller chunks: git push --mirror --no-verify --force
Or push branches/tags separately: git push origin --all
git push origin --tags
Clone with --filter=blob:none
This reduces the amount of data transferred: git clone --bare --filter=blob:none https://github.com/EXAMPLE-USER/OLD-REPOSITORY.git increase Git pack settings
Configure Git to handle larger packs:
Check GitHub’s size limits
GitHub has a hard limit of 100 MB per file and recommends repositories under 1 GB. If your repo is very large (hundreds of MBs or more), you may need to use Git LFS (docs.github.com in Bing) for large binaries. Since your repo is ~350 MB, it’s close to GitHub’s recommended size ceiling. I’d suggest trying the SSH push first, and if that still fails, push branches and tags separately instead of mirroring in one massive operation.

[muezrehman]

1. Clone the source repository as a mirror

git clone --mirror https://github.com/EXAMPLE-USER/OLD-REPOSITORY.git

2. Go into the mirrored repository

cd OLD-REPOSITORY.git

3. Point origin to the new repository

git remote set-url origin https://github.com/EXAMPLE-USER/NEW-REPOSITORY.git

4. Push everything to the new repository

git push --mirror

Or as one block:
git clone --mirror https://github.com/EXAMPLE-USER/OLD-REPOSITORY.git && cd OLD-REPOSITORY.git && git remote set-url origin https://github.com/EXAMPLE-USER/NEW-REPOSITORY.git && git push --mirror

⚠️ Make sure NEW-REPOSITORY already exists on GitHub before running git push --mirror, otherwise the push will fail.

[alisulmanpro]

GitHub Repo Copy Problem & Fix

What is the Problem?

You want to copy an old GitHub repo into a brand new repo (not as a fork).
You followed the official guide:
git clone --bare OLD-REPO then git push --mirror NEW-REPO

But you get this error:

error: RPC failed; curl 18 Transferred a partial file
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly

Your repo is big (~350 MB with 326k objects). Even after setting `http.postBuffer 2147483648` the push still fails.

Simple Solution (Works Most Times)

Step 1: Make New Empty Repo on GitHub

• Create NEW-REPO (keep it empty — no README).

Step 2: Run These Commands

# Clone as mirror
git clone --mirror https://github.com/YOUR-USERNAME/OLD-REPO.git

# Go inside
cd OLD-REPO.git

# Point to new repo
git remote set-url origin https://github.com/YOUR-USERNAME/NEW-REPO.git

# Push everything
git push --mirror

Replace YOUR-USERNAME, OLD-REPO and NEW-REPO.

Quick Fix for the RPC Error

Before pushing, run this:

git config http.postBuffer 524288000

Or try SSH (more stable):

git remote set-url origin git@github.com:YOUR-USERNAME/NEW-REPO.git
git push --mirror

Done!

Refresh the new repo on GitHub. All files, history and branches are now copied exactly.

Just copy the whole thing above and save as github-copy-fix.md

[edgarbc]

Thanks! this was the closest to the solution so I will assign this as the answer :)

[code-with-bhumi]

Hello @edgarbc

The Solution: Switch to SSH with Ed25519

The RPC failed; curl 18 error is a protocol-level timeout or buffer issue with HTTPS. Switching to SSH removes the reliance on http.postBuffer and provides a more stable stream for your 350MB+ migration.

1. Generate the Ed25519 Key Pair: Ed25519 is the most modern and efficient public-key algorithm available in Git today.

ssh-keygen -t ed25519 -C "your_email@example.com"

When prompted to "Enter a file in which to save the key," just press Enter to accept the default.

2. Add Key to the SSH Agent
To ensure your system uses the key automatically without asking for your passphrase every time:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

3. Add the Public Key to GitHub : Copy the contents of your public key to your clipboard

• Windows (Git Bash/PowerShell): cat ~/.ssh/id_ed25519.pub | clip
• macOS: pbcopy < ~/.ssh/id_ed25519.pub
• Linux: cat ~/.ssh/id_ed25519.pub

Action: Go to your GitHub SSH Settings, click New SSH Key, and paste the content.

4. Update your Remote and Mirror Push
Now, go back to your local bare clone and swap the HTTPS URL for the SSH URL.

• Navigate to your bare clone folder
  cd OLD-REPOSITORY.git
• Change the remote URL to the SSH format
  git remote set-url origin git@github.com:USERNAME/NEW-REPOSITORY.git
• Verify the change
  git remote -v
• Perform the final mirror push
  git push --mirror

Why this fixes the issue:

• No Buffer Limits: SSH doesn't use the http.postBuffer. It streams the data directly, avoiding the curl 18 partial file error.
• Persistent Connection: SSH is less likely to be interrupted by the server or middle-layer proxies during large transfers.
• Efficiency: Ed25519 keys are smaller and faster to verify than RSA, making the initial "handshake" nearly instant.

[edgarbc]

Thanks for all the suggestions and help! At the end I found the problem. When you create the new repo, you need to make sure it is completely empty (no README, no branches, etc). What I did was to delete the new repo and start from scratch. I had used copilot to initiate the previous new repo giving copilot instructions to do the copy, it created a PR...

After creating a empty new repo from scratch, the approach that I described at the top works just fine. 😁