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

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.

  • How to keep Drupal up to date with the GitHub repo?
  • Is it true in Mercurial (hg), the same as Git, that a revision you committed may only have code not modified by you? (a merge)
  • Is there a name for the merge conflict syntax Git uses?
  • Git: merging public and private branches while while keeping certain files intact in both branches
  • Git push to non-bare repository confusion
  • What is the value-add of Repo (+git)?
  • > 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?

  • `git show` not working: “fatal: Path exists on disk, but not in ”
  • golang docker private github repository
  • What is a 'dirty' Submodule?
  • Deleting a commit in Between other commits
  • Is it possible to accept user input as part of a remote git post-receive hook?
  • Team City git push hangs the build
  • One Solution collect form web for “What is the difference between clone and mkdir->cd->init->remote-add->pull?”

    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.

    Git Baby is a git and github fan, let's start git clone.