git init new from existing repository

Question

So I had an existing repository on github and I want to now push the same files into a new repository. I run git init in the terminal and it says "Reinitialized existing Git repository in..."

So how can I push the files into my new repo?

Answer 1

If you don't run any git command before as you run git init and this mistake shows you. You can try to delete .git file in a folder with your project. Just config to show hidden folders. It helped me.

Answer 2

You claimed in a comment that:

I deleted the old repo

But in fact you didn't:

Reinitialized existing Git repository in ...

As you can see from this message, Git is "reinitializing" the existing repository. This basically does nothing at all.¹

Remember that a repository is not "a bunch of files", it is a collection of commits. More precisely, a repository consists, at its heart, of two databases:

• The main database, which is copied by cloning, holds all of Git's internal objects. This includes your commits as internal commit objects, along with three other object types that make the commit objects work in the way we expect.

• The secondary database holds all of the names by which you can find commits. This includes branch names, tag names, remote-tracking names, and other names. This database is not copied, at least not directly, by cloning: the Git that is doing the cloning reads it, but modifies what is to be stored, so that the new clone of some existing repository normally has all the commits but none of the branches.

  (At the end of the cloning process, the Git that is doing the cloning normally creates one new branch name in the new repository. The branch name that gets created here identifies the same commit as some name in the source repository. You choose which new branch name to create, if any, with arguments to your git clone command; if you don't choose one, your Git picks a branch to create based on a suggestion made by the other Git, which looks at the source repository. GitHub and other hosting servers call this recommendation the default branch. They need a term for this because the way they set the recommendation is through their web interfaces. In fact, though, it's simply whichever branch name HEAD in the source repository is attached-to.)

The files that you see and work with, when you work inside a Git repository on your computer, are not in the repository. They are in your working tree or work-tree. The repository is normally contained within the .git directory at the top level of your work-tree.²

The phrase not in the repository here is doing some fairly heavy-duty work. What I mean is this:

• Git initially copies the files that are in some commit out of the commit into your work-tree.
• The files that are stored inside each commit are stored in a special, read-only, Git-only, compressed and de-duplicated format. Most programs can't read these files at all. That's why Git must copy them out to ordinary, read/write files.
• Once they're copied out of the commit, they're not Git's files any more. They are yours, to do with as you see fit. You may change them, combine them, separate them, remove them, or even fold, spindle / spike, bend, or otherwise mutilate them as you wish. They are yours, not Git's.
• This is also why, to get those files to go into a new commit, you keep having to run git add. The git add command copies the files back into Git (re-compressing and re-de-duplicating them, making them ready to be committed).

This means that to delete a repository, you must remove the .git directory itself. Regardless of how many other copies of that repository exist—remember that each git clone copied all the commits, which we usually call a "copy of the repository"³—this particular repository is in the .git directory.

---

¹Its main function is to copy a new hook template directory into place. If you have not adjusted your existing hooks, and are using the same standard hook template as before, nothing actually happens here. If you're using a different template directory, this sort of "reinitializing" can be useful. I have not heard of anyone actually doing this, but it's certainly possible that someone out there does it as a matter of routine.

²In submodules, the repository is often moved elsewhere, and instead of a .git directory, you find a .git file. Repositories that are not acting as submodules can use this mechanism as well, and working trees made with git worktree add use this mechanism to refer to the repository proper from the added work-tree.

³Despite git clone not copying any of the branch names, the clone is usually just as good as a full copy, because the owner of the copy can now create a branch name for each of the remote-tracking names that they have in their clone. Those remote-tracking names are the result of copying your clone's branch names. As soon as they make such names, they have all the same branches that you have.

If they like, they can copy each remote-tracking name to two branch names, after which they have twice as many branches as you have. This is the thing about branches in Git: they literally don't matter. It's not a matter of branch names. Those are not valuable currency, in Git. They're just bookmarks, sort of. What matters in Git are the commits, and the clone has all of the commits. There are some exceptions to this rule, especially for shallow and/or single-branch clones, but in general, cloning copies all the commits and none of the branches, and that makes a complete copy, because branch names simply don't matter.

As a short-cut, one can use git clone --mirror to make the clone such that it copies the entire names database as well. However, if you plan to use this other than as a true mirror, you will need to make some small post-clone adjustments.

---

Conclusion

Whether you want to delete the repository or not depends on whether you want to keep the history. History, in Git, is the set of commits in the repository. We find these commits by starting from some name—a branch name, or a tag name, or a remote-tracking name, or whatever—and having Git work backwards through the history, as stored in the commits. We get the files from a commit using git checkout or (in 2.23 and later) git switch. (There are additional tools, like git archive, that can get files out of a commit. Checkout and switch are merely the main tools.)

To keep the history, keep the commits—i.e., the repository. To start with a new history, i.e., just one new commit, discard the repository—remove the .git directory from your working tree—and create a new repository with git init, then add your files and run git commit. Note that if you remove the repository, you remove all the commits, so the history is now gone. (Any other clones of the original repository, stored elsewhere, will still remain, of course.)

Answer 3

You can try this:

remove the old 'origin' remote and add new origin remote

git remote remove origin
git remote add origin [new_repo_path].git

Add all files and commit the changes

git init .
git add -A
git commit -am "Initial commit"

Now push the files.

git push