Huh? I’m talking about existing code being in a dir, then initting a git repo there, creating a pendant on your hoster of choice and then pushing it there. Wouldn’t cloning the repo from step 3 to the code from step 1 overwrite the contents there?
There are multiple solutions to this without using --force.
Move the files, clone, unmove the files, commit, push being the most straightforward that I can summon at this time… but I’ve solved this dozens of times and have never use --force.
If your remote is completely empty and has no commits, you can just push normally. If it has an auto-generated “initial commit” (pretty sure Github does something like that), you could force push, or merge your local branch into the remote branch and push normally. I think cloning the repo and copying the contents of your local repo into it is the worst option: you’ll lose all local commits.
True, in the situation with a local history maybe it’s worthwhile to --force to nuke an empty remote. In that case it is practical to do so. I just typically like to find non-force options.
If it’s a single, generated, “initial” commit that I actually want to keep (say, for ex I used the forge to generate a license file) then I would often rebase on top of it. Quick and doesn’t get rid of anything.
Yeah, I was thinking of a new repo with no existing code.
In your case you’d want to uncheck the creation of a readme so the hosted repo is empty and can be pushed to without having to overwrite (force) anything.
If your remote is completely empty and has no commits, you can just push normally. If it has an auto-generated “initial commit” (pretty sure Github does something like that), you could force push, or merge your local branch into the remote branch and push normally. I think cloning the repo and copying the contents of your local repo into it is the worst option: you’ll lose all local commits.
Huh? I’m talking about existing code being in a dir, then initting a git repo there, creating a pendant on your hoster of choice and then pushing it there. Wouldn’t cloning the repo from step 3 to the code from step 1 overwrite the contents there?
There are multiple solutions to this without using --force.
Move the files, clone, unmove the files, commit, push being the most straightforward that I can summon at this time… but I’ve solved this dozens of times and have never use --force.
If your remote is completely empty and has no commits, you can just push normally. If it has an auto-generated “initial commit” (pretty sure Github does something like that), you could force push, or merge your local branch into the remote branch and push normally. I think cloning the repo and copying the contents of your local repo into it is the worst option: you’ll lose all local commits.
True, in the situation with a local history maybe it’s worthwhile to --force to nuke an empty remote. In that case it is practical to do so. I just typically like to find non-force options.
If it’s a single, generated, “initial” commit that I actually want to keep (say, for ex I used the forge to generate a license file) then I would often rebase on top of it. Quick and doesn’t get rid of anything.
You can also just tell GitHub to not do that.
Yeah, I was thinking of a new repo with no existing code.
In your case you’d want to uncheck the creation of a readme so the hosted repo is empty and can be pushed to without having to overwrite (force) anything.
If your remote is completely empty and has no commits, you can just push normally. If it has an auto-generated “initial commit” (pretty sure Github does something like that), you could force push, or merge your local branch into the remote branch and push normally. I think cloning the repo and copying the contents of your local repo into it is the worst option: you’ll lose all local commits.