Git Clone Parameter

Question

It would be nice to have a parameter on 'git clone' that not only clones the repo, but also creates local branches for ALL the branches that are in the repo. I'm new to git, but I found it very confusing to understand the difference between "remote" , "remotes". Is it in the cloned repo, or is it in a remote place? If its local, why doesn't it get shown when I do 'git branch' but when I do 'git branch -a'. For example, I create a project locally with multiple branches, push it, delete it locally and clone it back to my machine. On a 'git branch' I would only see the head branch. I understand that there are projects that have a lot of branches that are not needed for that specific developer, but still it would be nice if one could specify this at clone time. Something like 'git clone -createLocalBranchesForAllBranches' . Of course the param shouldn't be that long. I could write a script with for each in but thats way too much hassle and effort for something that should be there already and I don't think I am the first to get confused by this.

Answer 1

$ git for-each-ref --format="%(refname)" refs/remotes/origin/ | sed 's/refs/remotes/origin///;/HEAD|master/d' | xargs git checkout -b

(completely untested ofcourse)

Do you see what the problem is immediately? There's nothing special about "origin": I could have branches with the same name on several remotes. Without detaching local branches from remote branches, there
is no distributed workflow: your central workflow is just a special case.

Answer 2

Try:

$ git clone theRepo
$ git fetch origin refs/heads/*:refs/heads/*

(untested). There may be ways to write the same shorter, but I've lost track of what is and what is not possible in refspec.

Answer 3

Not very interested, for a few reasons:

(1) It is actively harmful if the aim is to blur the distinction between local branches and remote-tracking branches. New users will be in a lot of hurt if they are not aware that the 'master' branch in their repository is unique and different from the 'master' branch of everybody else's repository and the 'origin' remote repository they cloned from.

(2) It is not necessary. You can do interesting things to the history on your local branch, like creating new commits to grow the branch, only after checking it out. And modern Git lets you say

 $ git checkout topic

and it DWIMs the request to "check out the topic branch" to do the equivalent of

 $ git branch -t topic origin/topic && git checkout topic

when 'topic' does not exist as your local branch and there is a single remote (i.e. 'origin') that has a remote-tracking branch of that same name 'topic'. This lets you create a corresponding local branch lazily any time you want to work on extending the work on a branch taken from the remote, and output from "git branch --list" to be meaningful: it only lists your local branch, the ones you have already said that you are interested in working on in this repository.

(3) It makes "git branch --list" output less useful if you create local branches that correspond to all the branches taken from the remote. You cannot tell which ones you have worked on and which ones you haven't even touched yet.

Having said that, it is fairly trivial to script it, if you reallywant to do so, ignoring all of the above downsides. Something like:

 git for-each-ref --format='%(refname)' refs/remotes/origin/ |
 sed -e 's|^refs/remotes/origin/||' -e '/^HEAD$/d' |
 while read branchname
 do
 git show-ref -q --verify "refs/heads/$branchname" ||
 git branch -t "$branchname" "origin/$branchname"
 done

But for the reasons stated, it is not a particularly good way to work to start from many local branches that are copies of all the remote-tracking branches, many of which you may not even touch, so I personally do not think we would want to add such an option to "clone". The implementation would be fairly trivial, as you can see from the "trivial script" above, but it would encourage a wrong workflow.

Older Git around 1.4.x days used to conflate remote-tracking branches and local branches, and threw everything in refs/heads/hierarchy, which had the exact set of problems above, and that is why modern Git uses refs/remotes/origin/ hierarchy to store the remote-tracking branches separately, for less cluttered local branch namespace.