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.
> mkdir "exampleProject" > cd "exampleProject" > git init > git remote add origin email@example.com:exampleUser/exampleProject.git > git pull origin master
Secondly, I could clone the remote.
> git clone firstname.lastname@example.org: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?
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.
git pullwon’t create any remote branches. If the remote has several branches, the clone creates remote branches
remotes/origin/bar, … in your repository. A
git fetch originwould 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
It’s short. Why do more work?
It’s got handy options to change its behavior. Things like
--sharedwould 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.