{"thread":{"id":"48198","subject":"[RFC] git clone add option to track all remote branches","startedAt":"2018-04-02T01:50:47Z","lastAt":"2018-04-02T09:29:48Z","messageCount":5,"participants":["Yubin Ruan","Junio C Hamano","Randall S. Becker","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"343564","messageId":"20180402015035.mzgye6apwn3igch5@HP","threadId":"48198","inReplyTo":null,"subject":"[RFC] git clone add option to track all remote branches","fromName":"Yubin Ruan","fromEmail":"ablacktshirt@gmail.com","sentAt":"2018-04-02T01:50:35Z","receivedAt":"2018-04-02T01:50:47Z","isPatch":false,"sender":{"key":"ablacktshirt@gmail.com","avatar":null},"body":"Hi,\n\nI am writing to ask that whether or not you think will be appropriate to add\nan option to \"git clone\" so that whenever a repo is cloned, branches are\ncreated automatically to track corresponding remote branches. (or is there any\nequivelant option?)\n\nYou can obviously do this by a bash command like this\n\n    git branch -r | grep -v '\\->' | while read remote; do git branch --track \"${remote#origin/}\" \"$remote\"; done\n\nbut it will be better if we can have an option in \"git clone\".\n\nRegards,\nYubin\n"},{"id":"343565","messageId":"xmqqwoxqz56y.fsf@gitster-ct.c.googlers.com","threadId":"48198","inReplyTo":"20180402015035.mzgye6apwn3igch5@HP","subject":"Re: [RFC] git clone add option to track all remote branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-04-02T02:56:53Z","receivedAt":"2018-04-02T02:57:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yubin Ruan <ablacktshirt@gmail.com> writes:\n\n> I am writing to ask that whether or not you think will be appropriate to add\n> an option to \"git clone\" so that whenever a repo is cloned, branches are\n> created automatically to track corresponding remote branches. (or is there any\n> equivelant option?)\n>\n> You can obviously do this by a bash command like this\n>\n>     git branch -r | grep -v '\\->' | while read remote; do git branch --track \"${remote#origin/}\" \"$remote\"; done\n>\n> but it will be better if we can have an option in \"git clone\".\n\nI am not sure how it will be more useful than what you already have.\nIn short, you are getting \"all of the remote branches\" but with a\ntwist.  You get them \"on demand\".\n\nWith your hypothetical \"clone\" command that makes copies of each and\nevery remote branch to a local one, you can ask \"git branch<Enter>\"\nto show all of them (i.e. \"please list what is happening at the\ncentral repository\").  With the current system, you would instead\nneed to ask \"git branch -r<Enter>\", which may be a bit more to type.\n\nAlso when you want to look at or work on top of a remote branch, say\n\"frotz\", you do not have to do \"git checkout -b frotz origin/frotz\"\nto create one, as your hypothetical \"clone\" would have already\ncreated it when you cloned.  But I think \"git checkout frotz\" in\nsuch a situation would create a local \"frotz\" branch out of the\n\"origin/frotz\" remote-tracking branch with the current system, so\nI do not think your hypothetical \"clone\" is all that more useful.\n\nAnd there certainly is a huge downside.\n\nIf you are really doing your own development, then you would have\nsome topic branches of your own, with forks of some (but most likely\nnot all, especiallyi when there are many branches at the upstream)\nbranches you got from the upstream, and \"git branch --list\" that\nshows only your own and what you are interested in (i.e. those that\nyou actually bothered to \"git checkout <branchname>\") without\nshowing random other branches that exist at the remote but do not\ninterest you is a feature.  Your hypothetical \"clone\" that\nindiscriminatedly forks all branches at remote locally will destroy\nthe usefulness of it.\n"},{"id":"343566","messageId":"xmqqsh8ez41b.fsf@gitster-ct.c.googlers.com","threadId":"48198","inReplyTo":"xmqqwoxqz56y.fsf@gitster-ct.c.googlers.com","subject":"Re: [RFC] git clone add option to track all remote branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-04-02T03:21:52Z","receivedAt":"2018-04-02T03:22:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> If you are really doing your own development, then you would have\n> some topic branches of your own, with forks of some (but most likely\n> not all, especiallyi when there are many branches at the upstream)\n> branches you got from the upstream, and \"git branch --list\" that\n> shows only your own and what you are interested in (i.e. those that\n> you actually bothered to \"git checkout <branchname>\") without\n> showing random other branches that exist at the remote but do not\n> interest you is a feature.  Your hypothetical \"clone\" that\n> indiscriminatedly forks all branches at remote locally will destroy\n> the usefulness of it.\n\nRelated to this, a feature I have long thought we wished to have is\ncomplete opposite of this.  After creating and working on a local\ntopic branch and then concluding the work on it, a user would \"git\npush\" the branch out to a remote, and then check out a different\nbranch (e.g. the 'master' branch).  I wish we had a mode that would\nautomatically *delete* the local topic branch that has already been\npushed out (and more importantly, a branch that I have *done* with,\nat least for now), to unclutter my local branch namespace.  When I\nwant to further work on it, I can ask \"git checkout\" to dwim to\nrecreate one on demand.\n\nOf course, there are some wrinkles due to pesky impleemntation\ndetails (e.g. the \"autonuke-and-recreate\" would lose reflog), but I\ndo not think it is fundamental hurdle.\n\n\n"},{"id":"343568","messageId":"005d01d3ca35$0d4576d0$27d06470$@nexbridge.com","threadId":"48198","inReplyTo":"xmqqsh8ez41b.fsf@gitster-ct.c.googlers.com","subject":"RE: [RFC] git clone add option to track all remote branches","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2018-04-02T03:45:27Z","receivedAt":"2018-04-02T03:45:41Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"\nOn April 1, 2018 11:22 PM Junio C Hamano wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n> > If you are really doing your own development, then you would have some\n> > topic branches of your own, with forks of some (but most likely not\n> > all, especiallyi when there are many branches at the upstream)\n> > branches you got from the upstream, and \"git branch --list\" that shows\n> > only your own and what you are interested in (i.e. those that you\n> > actually bothered to \"git checkout <branchname>\") without showing\n> > random other branches that exist at the remote but do not interest you\n> > is a feature.  Your hypothetical \"clone\" that indiscriminatedly forks\n> > all branches at remote locally will destroy the usefulness of it.\n> \n> Related to this, a feature I have long thought we wished to have is\ncomplete\n> opposite of this.  After creating and working on a local topic branch and\nthen\n> concluding the work on it, a user would \"git push\" the branch out to a\n> remote, and then check out a different branch (e.g. the 'master' branch).\nI\n> wish we had a mode that would automatically *delete* the local topic\nbranch\n> that has already been pushed out (and more importantly, a branch that I\n> have *done* with, at least for now), to unclutter my local branch\n> namespace.  When I want to further work on it, I can ask \"git checkout\" to\n> dwim to recreate one on demand.\n> \n> Of course, there are some wrinkles due to pesky impleemntation details\n> (e.g. the \"autonuke-and-recreate\" would lose reflog), but I do not think\nit is\n> fundamental hurdle.\n\nI'm a little skeptical and confused here. The original RFC does not appear\nto stipulate that this is isolated to a single bare. If B,C,D all clone\nA.git from one server, it might be ok. If B clones A.git, and C clones B,\nand D mirrors C, where would the remote tracking occur. The main value, as a\nrepo admin of A.git would be to know everything, but that's unlikely.\nStating the obvious rub is, in a DVCS, where connections are not guaranteed,\none can easily move a clone or delete a clone, and your tracking branch\nbecomes worthless. You might never know about C/D mirrors or even be able to\nestablish a connection between A.git and those two, in practice - I have\nexamples of those.\nOTOH I have been toying with suggesting a solution to this for a couple of\nyears, differentiating a transient clone from a (pick a term) authentic\nclone, the latter which has some blockchainish so that git will whine\nwithout a valid signature on the clone. Changing the clone without\ncommunicating with the upstream to revalidate it (deferrals could be\nimplemented), temporarily or permanently invalidates the authentic clone so\nit effective becomes pruneable, like a worktree. I see a very deep potential\nrabbit hole here that detracts from DVCS principles unless we do have the\nconceptual split of the two classes of clones. rm .git is just too easy and\ntoo frequent an operation to just ignore the implication of the deliberate\nloss of tracking that is highly unlikely to be trackable by the farthest\nupstream, resulting in a whole lot of clutter with no way back.\nAlternatively, if the downstreams periodically are forced to revalidate the\ntracking branches, then you have sometime potentially workable but annoying\nat best, and impractical in some security policies at worst.\n\nJust my $0.02 from managing boat-loads of 4 and 5 level deep repositories.\n\nCheers,\nRandall\n\n"},{"id":"343572","messageId":"874lkuvtve.fsf@evledraar.gmail.com","threadId":"48198","inReplyTo":"20180402015035.mzgye6apwn3igch5@HP","subject":"Re: [RFC] git clone add option to track all remote branches","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-04-02T09:29:41Z","receivedAt":"2018-04-02T09:29:48Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Apr 02 2018, Yubin Ruan wrote:\n\n> I am writing to ask that whether or not you think will be appropriate to add\n> an option to \"git clone\" so that whenever a repo is cloned, branches are\n> created automatically to track corresponding remote branches. (or is there any\n> equivelant option?)\n>\n> You can obviously do this by a bash command like this\n>\n>     git branch -r | grep -v '\\->' | while read remote; do git branch --track \"${remote#origin/}\" \"$remote\"; done\n\nAside from this specific suggestion, we should be careful when adding\nmore special snowflakes to git-clone that aren't available through\ngit-fetch or via after the fact config, such as git clone\n--single-branch which has no fetch equivalent (i.e. in finding out what\nthe remote HEAD is).\n\nActually now that I mention that it occurs to me that what you want\ncould just be a special case of generalizing our existing\n--single-branch feature. I.e. we would clone repos as:\n\n    [remote \"origin\"]\n    url = git@github.com:git/git.git\n    fetch = +refs/heads/*:refs/remotes/origin/*\n    branch = $symref(HEAD):refs/remotes/origin/HEAD:TRACK\n\nOr some other such syntax to create a refs/heads/master from the remote\nHEAD symref if it doesn't exist (note the lack of a +), then for your\nfeature:\n\n    branch = refs/heads/*:refs/remotes/origin/*:TRACK\n\nBut you could also do:\n\n    branch = +refs/heads/origin/*:refs/remotes/origin/*:TRACK\n\nOr whatever. I don't know what syntax would be sensible, but something\nlike this is a missing feature of our existing --single-branch feature,\nand because of that you can only get its semantics by re-cloning.\n"}]}