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.
Never have heard of that, but in the case of you also having a Readme that will be even more complicated, I imagine. So just adding -f is the easier option.
this guy would have force pushed onto main about 10 mins after this if he did have git
And then lost the reflog by
rm -rfing the project and cloning it again.God bless DCVS.
Tbf you have to do that for the first push, if a Readme file was autogenerated
You don’t if you just clone the repo you created.
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.
Does that still happen if you use the merge unrelated histories option? (Been a minute since I last had to use that option in git)
Never have heard of that, but in the case of you also having a Readme that will be even more complicated, I imagine. So just adding -f is the easier option.