top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Git Clone Parameter

+1 vote

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.

posted Jul 19, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

3 Answers

+1 vote

$ 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 Jul 19, 2013 by anonymous
+1 vote


$ 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 Jul 19, 2013 by anonymous
+1 vote

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
 git show-ref -q --verify "refs/heads/$branchname" ||
 git branch -t "$branchname" "origin/$branchname"

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.

answer Jul 19, 2013 by anonymous
Similar Questions
0 votes

We recently upgraded from Git 2.8 to 2.9 and saw an issue when there are multiple keys added to my ssh-agent.

I have two keys.
- KeyA (my company that has access to the repository I want to clone)
- KeyB (just my personal key with access to my personal stuff)

Having both keys in loaded and listed in ssh-add -L fails to clone the repository. I tried to change the order of the key in the agent but neither KeyA, KeyB nor KeyB, KeyA will work. The only case that works if I have KeyA loaded an no other key is added to the ssh-agent.

Having multiple Keys loaded works with Git 2.8 and Git 2.7 (I didn't try older versions)
Cloning fails with 'Unauthorized Access' of our Git provider. (It's Bitbucket in this case)

I read the Changelog for 2.9 and couldn't find any reference to changed key handling. Is there anything that I can add to the git clone command to get the old behavior?

+1 vote

I can get the latest revision number by command "git describe --tags", but how can I display a list of revisions or a particular revision based on the date of my commit id?

+1 vote

I wanted to avoid push if any of the files is deleted from the local git clone area. Can anyone please help me with that?

I am using Stash for repository management.

+3 votes

When we clone a remote GIT repository, all folders/files will be cloned. This will consume lot of disk space in our local machine.
Is there a way to clone only few folders & exclude others?

This is possible in clearcase snapshot view by changing load rules.

+2 votes

Cloning huge repositories like Linux kernel takes considerable amount of time. Is it possible to incorporate a multi-threaded simultaneous connections functionality for cloning? To what extent do we need to change the architecture of the current code and how large would be the scope of the work? That just seems an interesting idea to me and would liked to share it with the community.