Re: [RFC] git clone add option to track all remote branches
On Mon, Apr 02 2018, Yubin Ruan wrote: > I am writing to ask that whether or not you think will be appropriate to add > an option to "git clone" so that whenever a repo is cloned, branches are > created automatically to track corresponding remote branches. (or is there any > equivelant option?) > > You can obviously do this by a bash command like this > > git branch -r | grep -v '\->' | while read remote; do git branch --track > "${remote#origin/}" "$remote"; done Aside from this specific suggestion, we should be careful when adding more special snowflakes to git-clone that aren't available through git-fetch or via after the fact config, such as git clone --single-branch which has no fetch equivalent (i.e. in finding out what the remote HEAD is). Actually now that I mention that it occurs to me that what you want could just be a special case of generalizing our existing --single-branch feature. I.e. we would clone repos as: [remote "origin"] url = g...@github.com:git/git.git fetch = +refs/heads/*:refs/remotes/origin/* branch = $symref(HEAD):refs/remotes/origin/HEAD:TRACK Or some other such syntax to create a refs/heads/master from the remote HEAD symref if it doesn't exist (note the lack of a +), then for your feature: branch = refs/heads/*:refs/remotes/origin/*:TRACK But you could also do: branch = +refs/heads/origin/*:refs/remotes/origin/*:TRACK Or whatever. I don't know what syntax would be sensible, but something like this is a missing feature of our existing --single-branch feature, and because of that you can only get its semantics by re-cloning.
RE: [RFC] git clone add option to track all remote branches
On April 1, 2018 11:22 PM Junio C Hamano wrote: > Junio C Hamano writes: > > If you are really doing your own development, then you would have some > > topic branches of your own, with forks of some (but most likely not > > all, especiallyi when there are many branches at the upstream) > > branches you got from the upstream, and "git branch --list" that shows > > only your own and what you are interested in (i.e. those that you > > actually bothered to "git checkout ") without showing > > random other branches that exist at the remote but do not interest you > > is a feature. Your hypothetical "clone" that indiscriminatedly forks > > all branches at remote locally will destroy the usefulness of it. > > Related to this, a feature I have long thought we wished to have is complete > opposite of this. After creating and working on a local topic branch and then > concluding the work on it, a user would "git push" the branch out to a > remote, and then check out a different branch (e.g. the 'master' branch). I > wish we had a mode that would automatically *delete* the local topic branch > that has already been pushed out (and more importantly, a branch that I > have *done* with, at least for now), to unclutter my local branch > namespace. When I want to further work on it, I can ask "git checkout" to > dwim to recreate one on demand. > > Of course, there are some wrinkles due to pesky impleemntation details > (e.g. the "autonuke-and-recreate" would lose reflog), but I do not think it is > fundamental hurdle. I'm a little skeptical and confused here. The original RFC does not appear to stipulate that this is isolated to a single bare. If B,C,D all clone A.git from one server, it might be ok. If B clones A.git, and C clones B, and D mirrors C, where would the remote tracking occur. The main value, as a repo admin of A.git would be to know everything, but that's unlikely. Stating the obvious rub is, in a DVCS, where connections are not guaranteed, one can easily move a clone or delete a clone, and your tracking branch becomes worthless. You might never know about C/D mirrors or even be able to establish a connection between A.git and those two, in practice - I have examples of those. OTOH I have been toying with suggesting a solution to this for a couple of years, differentiating a transient clone from a (pick a term) authentic clone, the latter which has some blockchainish so that git will whine without a valid signature on the clone. Changing the clone without communicating with the upstream to revalidate it (deferrals could be implemented), temporarily or permanently invalidates the authentic clone so it effective becomes pruneable, like a worktree. I see a very deep potential rabbit hole here that detracts from DVCS principles unless we do have the conceptual split of the two classes of clones. rm .git is just too easy and too frequent an operation to just ignore the implication of the deliberate loss of tracking that is highly unlikely to be trackable by the farthest upstream, resulting in a whole lot of clutter with no way back. Alternatively, if the downstreams periodically are forced to revalidate the tracking branches, then you have sometime potentially workable but annoying at best, and impractical in some security policies at worst. Just my $0.02 from managing boat-loads of 4 and 5 level deep repositories. Cheers, Randall
Re: [RFC] git clone add option to track all remote branches
Junio C Hamano writes: > If you are really doing your own development, then you would have > some topic branches of your own, with forks of some (but most likely > not all, especiallyi when there are many branches at the upstream) > branches you got from the upstream, and "git branch --list" that > shows only your own and what you are interested in (i.e. those that > you actually bothered to "git checkout ") without > showing random other branches that exist at the remote but do not > interest you is a feature. Your hypothetical "clone" that > indiscriminatedly forks all branches at remote locally will destroy > the usefulness of it. Related to this, a feature I have long thought we wished to have is complete opposite of this. After creating and working on a local topic branch and then concluding the work on it, a user would "git push" the branch out to a remote, and then check out a different branch (e.g. the 'master' branch). I wish we had a mode that would automatically *delete* the local topic branch that has already been pushed out (and more importantly, a branch that I have *done* with, at least for now), to unclutter my local branch namespace. When I want to further work on it, I can ask "git checkout" to dwim to recreate one on demand. Of course, there are some wrinkles due to pesky impleemntation details (e.g. the "autonuke-and-recreate" would lose reflog), but I do not think it is fundamental hurdle.
Re: [RFC] git clone add option to track all remote branches
Yubin Ruan writes: > I am writing to ask that whether or not you think will be appropriate to add > an option to "git clone" so that whenever a repo is cloned, branches are > created automatically to track corresponding remote branches. (or is there any > equivelant option?) > > You can obviously do this by a bash command like this > > git branch -r | grep -v '\->' | while read remote; do git branch --track > "${remote#origin/}" "$remote"; done > > but it will be better if we can have an option in "git clone". I am not sure how it will be more useful than what you already have. In short, you are getting "all of the remote branches" but with a twist. You get them "on demand". With your hypothetical "clone" command that makes copies of each and every remote branch to a local one, you can ask "git branch" to show all of them (i.e. "please list what is happening at the central repository"). With the current system, you would instead need to ask "git branch -r", which may be a bit more to type. Also when you want to look at or work on top of a remote branch, say "frotz", you do not have to do "git checkout -b frotz origin/frotz" to create one, as your hypothetical "clone" would have already created it when you cloned. But I think "git checkout frotz" in such a situation would create a local "frotz" branch out of the "origin/frotz" remote-tracking branch with the current system, so I do not think your hypothetical "clone" is all that more useful. And there certainly is a huge downside. If you are really doing your own development, then you would have some topic branches of your own, with forks of some (but most likely not all, especiallyi when there are many branches at the upstream) branches you got from the upstream, and "git branch --list" that shows only your own and what you are interested in (i.e. those that you actually bothered to "git checkout ") without showing random other branches that exist at the remote but do not interest you is a feature. Your hypothetical "clone" that indiscriminatedly forks all branches at remote locally will destroy the usefulness of it.