767
Git, invented in 2005. Programmers on 2004:
(lemmy.eco.br)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 21 Mar 2025
767 points (98.9% liked)
Programmer Humor
22157 readers
3237 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
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.
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.
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.
You can also just tell GitHub to not do that.