Git Clone Parameter
Hi, 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 theRepo -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. I'd like to know your opinions about that and what you think about the suggestion. Allan.-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Clone Parameter
Allan Acheampong wrote: I could write a script with for each in but thats way too much hassle $ 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Clone Parameter
Am 7/19/2013 11:21, schrieb Allan Acheampong: Something like 'git clone theRepo -createLocalBranchesForAllBranches' Perhaps: $ 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. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Clone Parameter
Johannes Sixt j.s...@viscovery.net writes: Am 7/19/2013 11:21, schrieb Allan Acheampong: Something like 'git clone theRepo -createLocalBranchesForAllBranches' Perhaps: $ 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. That would overwrite your local branch and would not give you any tracking, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Clone Parameter
Ramkumar Ramachandra artag...@gmail.com writes: Allan Acheampong wrote: I could write a script with for each in but thats way too much hassle $ git for-each-ref --format=%(refname) refs/remotes/origin/ | sed 's/refs\/remotes\/origin\///;/HEAD\|master/d' | xargs git checkout -b (completely untested ofcourse) You would at least need xargs -n 1 for the produced command line to make any sense, and it is wasteful to actually check out each and every branch to the working tree only to create it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Clone Parameter
Allan Acheampong allanad...@gmail.com writes: ... 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'd like to know your opinions about that and what you think about the suggestion. 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 really want 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Clone Parameter
Junio C Hamano wrote: git branch -t $branchname origin/$branchname A couple of notes here: 1. I use git branch -u personally. Why the -t variant? 2. Don't we auto-track? (or is that only on checkout) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Clone Parameter
Junio C Hamano wrote: You would at least need xargs -n 1 for the produced command line to make any sense, and it is wasteful to actually check out each and every branch to the working tree only to create it. Right. xargs -n 1, git branch, and refname:short. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Clone Parameter
From: Junio C Hamano gits...@pobox.com Sent: Friday, July 19, 2013 4:02 PM Allan Acheampong allanad...@gmail.com writes: ... 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'. Allan, This (not being sure about local remote branches and distant remote branches, while coping with multiple remote servers) appears to be a common problem for new folks, which those well versed in the use of Git have become well used to so don't see the problem. For the uninitiated, the lack of distinct terminology can cause no end of confusion as most explanations presume that you will implicitly understand the context, which can't be true for such newbies. It doesn't help that the 'remotes' model of the Git DVCS fits a work flow style that isn't the same as the expectation of the newbie. For example, in a larger collaboration there can be many many branches (on a communal server) that essentially belong to other contributors which one would never be interested in, and you (and they) would want ignored. ... 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. Junio explains below how your suggestion of 'only the head branch' viewpoint is too limiting (among other things). That said, if you have a terminology for the distinction between the confusing aspects (once understood), then that would be worth something to help ease the path of understanding for others. I had the same confusions for a while, and even now have to use some of the awkward terminology I used above, so any improvements in that area would be useful. -- Branching models are an endless source of discussion! Philip ... I'd like to know your opinions about that and what you think about the suggestion. 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 really want 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Clone Parameter
Philip Oakley philipoak...@iee.org writes: Allan Acheampong allanad...@gmail.com writes: ... 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 the uninitiated, the lack of distinct terminology can cause no end of confusion as most explanations presume that you will implicitly understand the context, which can't be true for such newbies. True. * You work in a local repository. * You interact with repositories other than the local repository. Here, to interact mean exchange the history with, either by pushing the commits in the local repository to the other one(s), or fetching the commits in the other one(s) to the local repository. These other repositories are remote repositories from the point of view of the local repository. Note that you may have two repositories you use for working on the same project, one on your desktop and one on your notebook. As far as the repository on your notebook is concerned, the repository on your desktop, if you interact with it from the repository on your notebook, is a remote repository (and the one on the desktop views the one on the notebook as remote). * Often we call a remote repository just a remote. Especially when we give a convenience short-name to it, like origin. * When you clone from a repository to create a copy to work in, from that new repository's point of view, the original repository is a remote repository, and git clone configures things in the new repository so that you can conveniently interact with that original repository. The last part is what lets you say git fetch origin, for example, to interact with the origin remote. * Branches are local to each repository. It is merely a social convention that the primary branch in the repository you cloned from (i.e. your origin) is often called 'master', the primary branch in the local repository is called 'master', and you often interact with the history of the 'master' branch of the origin when you are on your 'master' branch. There is no stronger tie between their 'master' and your 'master' other than the social convention, but Git makes it easier for you to work that way by setting a few configuration variables. * Some of the social conventions, and the configuration Git sets up to let you follow them easily, allows you to find out where the tips of branches at your remotes were, when you last observed them (remember, Git is distributed, so you do not ask right now; instead you have when you last observed and make an observation right now separately). This is achieved by keeping the record of the last observation in remote-tracking branches. The last observed value of the 'master' branch of the remote repository origin is stored as 'origin/master' (its full name is 'refs/remotes/origin/master', but you rarely have to spell it out) remote-tracking branch. CAVEAT: some older documentation call a remote-tracking branch just remote branch, but we have been trying to move away from that practice, as it is confusing, because the 'master' branch at the 'origin' remote is often called a 'remote branch'. When you see 'remote branch', you need to make sure which one the writer meant. * git fetch (and git pull, which internally invokes git fetch) is a way to make the observation now. git fetch origin updates your remote-tracking branches for the origin. * git pull (and git pull --rebase) is a way to do the fetch above and then integrate the history of the branch at the remote (which now you know its latest state, because you just observed it) with the history you have on your branch. Again, these branches may be named 'master' but the user needs to be aware that they are two separate branches (your 'master' branch is just as a different entity from the 'master' branch of the remote repository as it is your 'next' or any other branch). To make it easier to work, git configures the history of which branch you obtained/observed from what remote is to be integrated with your history per your local branch. Immediately after git clone, you will typically have your 'master' branch, and the branch knows that it wants to integrate with the 'master' branch at 'origin' remote. So git pull becomes: - git fetch origin, because you will integrate with the history that comes from that remote, not other remotes; - which updates 'origin/master' remote-tracking branch, and possibly other remote-tracking branches under 'origin/'; and - integrate your branch with the history of 'origin/master' remote-tracking branch. We say your 'master' branch is set to integrate with
