26

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 git@github.com:exampleUser/exampleProject.git
> git pull origin master

Secondly, I could clone the remote.

> git clone git@github.com: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?

Rupert Madden-Abbott
  • 12,899
  • 14
  • 59
  • 74

1 Answers1

29

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.

Cascabel
  • 479,068
  • 72
  • 370
  • 318
  • 1
    Thanks for your answer! It was very helpful. My reason for asking is not because I want to reinvent clone but rather to understand exactly what it is doing but your advice is very valid. – Rupert Madden-Abbott Nov 05 '10 at 18:47
  • @Rupert: Ah, cool. I think it was the fact that you listed the manual method first that made me think you were considering using it. – Cascabel Nov 05 '10 at 18:57
  • @Jefromi: Another way to do what you're doing with those two `git config` commands is: `git branch --set-upstream master origin/master` That adds the same `[branch "master"]` section to the `.git/config` file. It's like `git branch --track master origin/master` except you use it when the master branch already exists locally. – bjnord Mar 10 '12 at 05:06