What is the difference between clone and mkdir->cd->init->remote-add->pull?

Question

After setting up a repo on Github, there seems to be two ways to pull that repo into a local repo.

Firstly, I could create a directory, initialize a blank repo, add a remote and then pull changes from the remote.

> mkdir "exampleProject"
> cd "exampleProject"
> git init
> git remote add origin [email protected]:exampleUser/exampleProject.git
> git pull origin master

Secondly, I could clone the remote.

> git clone [email protected]:exampleUser/exampleProject.git

Is cloning just a shortcut for the 5 step version above or does it do anything else as well? Will I run into difficulty if I use one method over the other?

Answer 1

A lot of commands, whether git commands or common programs, do things in one line you could otherwise do in ten. It's always good to save work!

That said, your steps are close to, but not entirely the same as, what git clone does. I can think of a few differences, all to do with branches:

• If, for some reason, the remote's HEAD is not master, the clone will do the right thing - give you a branch named the same as the remote's, instead of master. This is rare, but a good detail to be aware of.

• Your git pull won't create any remote branches. If the remote has several branches, the clone creates remote branches remotes/origin/foo, remotes/origin/bar, ... in your repository. A git fetch origin would take care of that in your listed steps.

• You also haven't set up your master branch to track origin's, which the clone does. You could add this to your listed steps as git config branch.master.remote origin; git config branch.master.merge refs/heads/master. This is very significant - with your steps, if you have master checked out and you type git pull, it won't know what to do.

It's possible I've missed a thing or two. As for difficulties one way or the other, even assuming you iron out all the differences between a default clone and a "manual clone", my advice would be not to reinvent git clone:

• It's short. Why do more work?

• It's got handy options to change its behavior. Things like --shared would be really difficult to add to your listed commands.

• It's guaranteed to do the right thing now and in the future. What if you missed a detail, like the ones above? What if git added a global config parameter that affected clones? You'd have to change your commands to take it into account, but git clone would already know.