CODEWITHSUNDEEP
gitgithub
eyuelt
eyuelt

Reputation: 1406

Differences between these methods of importing existing Git repositories into GitHub?

I have a local Git repository on my server that I want to import to GitHub. I was looking around to find out how to do this and came across two different methods, both given by GitHub.

According to the GitHub Help page Importing an external Git repository, the way to import an existing Git repository into GitHub is to create a temporary bare clone of the original repo, then push it to GitHub with the "mirror" option. The page offers the following sequence of commands:

git clone --bare https://githost.org/extuser/repo.git

cd repo.git
git push --mirror https://github.com/ghuser/repo.git

cd ..
rm -rf repo.git

However, whenever you create a new repository on GitHub, the empty repo page gives a different set of instructions on how to import an existing repository. It says to simply push the original repo to GitHub. The page offers the following sequence of commands.

git remote add origin [email protected]:ghuser/repo.git
git push -u origin master

In both cases, the empty repo ghuser/repo should already exist on GitHub before executing the given commands. The only difference I see between the two methods is that the first one doesn't add a remote for the GitHub repo.

I tried both methods to test them out and they both worked. The two repositories look exactly the same. What is the difference between these two methods? If both methods have the same effect, why does the GitHub help page add the extra steps of creating a bare clone of the repo and using the mirror option?

Upvotes: 7

Views: 2997

Answers (1)

user456814
user456814

Reputation:

Presumably the difference is that if you just created a new repo, you don't have any existing data (references, tags, etc) associated with it, so it's a simple matter to just push the (relatively) empty repo to GitHub like so:

git push -u origin master

However, if you're importing an existing repo that's been around a while, you'll probably want to push any existing data (tags, etc) that it has, which git push won't do by default without the --tags or --mirror option.

push --mirror

From the Pro Git book Chapter 2.6 Git Basics - Tagging § Sharing Tags (emphasis mine):

By default, the git push command doesn’t transfer tags to remote servers. You will have to explicitly push tags to a shared server after you have created them...If you have a lot of tags that you want to push up at once, you can...use the --tags option to the git push command. This will transfer all of your tags to the remote server that are not already there.

The GitHub help page Importing an external Git repository that you reference yourself explains the purpose of the --mirror option like so (emphasis mine):

Push the local cloned repository to GitHub using the "mirror" option, which ensures that all references (i.e. branches, tags, etc.) are copied to the imported repository.

You can also read more about the --tags and --mirror options at git-push(1).

clone --bare

As for the purpose of the clone --bare option, it probably again has to do with the fact that you're probably importing an older existing repo that's been around for a while, and already has data in it, compared to a new repo. Importing an external Git repository explains it like this:

Make a "bare" clone of the repository (i.e. a full copy of the data, but without a working directory for editing files) using the external clone URL. This ensures a clean, fresh export of all the old data.

This is the explanation of git clone --bare from git-clone(1):

...the branch heads at the remote are copied directly to corresponding local branch heads, without mapping them to refs/remotes/origin/. When this option is used, neither remote-tracking branches nor the related configuration variables are created.

Upvotes: 2

Related Questions