{"thread":{"id":"43070","subject":"Re: git bug? + question","startedAt":"2006-11-02T05:56:51Z","lastAt":"2006-11-06T12:32:27Z","messageCount":38,"participants":["Junio C Hamano","Shawn Pearce","Karl Hasselström","Sean","Andy Whitcroft","Martin Waitz","Jeff King","Josef Weidendorfer","Miles Bader","Santi Béjar","Andy Parkins","Jakub Narebski","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"295223","messageId":"buoejsme6ho.fsf@dhapc248.dev.necel.com","threadId":"43070","inReplyTo":null,"subject":"git bug? + question","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2006-11-02T05:56:51Z","receivedAt":"2006-11-02T05:56:51Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"Hi,\n\nI tried the following sequence of commands to make two clones of a\nremote repository, but got an error:\n\n   $ git clone --use-separate-remote ssh://fp.gnu.org/~/git/snogray.git snogray-git\n   $ git clone --use-separate-remote --reference snogray-git ssh://fp.gnu.org/~/git/snogray.git imp-sample\n   error: refs/reference-tmp/refs/remotes/origin/HEAD points nowhere!\n\nIs this a real error, or bad usage?\n\nAlso, a question:  Is there anyway to make git-clone use\n--use-separate-remote by default?  I'm trying for a \"lots of branches in\na single shared remote repository\" style, and use-separate-remote seems\nmore sane for this usage.\n\nI'm using git version 1.4.3.3.\n\nThanks,\n\n-Miles\n\n-- \n\"I distrust a research person who is always obviously busy on a task.\"\n"},{"id":"295085","messageId":"7v4pthmew1.fsf@assigned-by-dhcp.cox.net","threadId":"43070","inReplyTo":"buoejsme6ho.fsf@dhapc248.dev.necel.com","subject":"Re: git bug? + question","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-03T02:40:30Z","receivedAt":"2006-11-03T02:40:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader <miles.bader@necel.com> writes:\n\n> Also, a question:  Is there anyway to make git-clone use\n> --use-separate-remote by default?  I'm trying for a \"lots of branches in\n> a single shared remote repository\" style, and use-separate-remote seems\n> more sane for this usage.\n\nThis was suggested last week on the list, and I think it is a\nsensible thing to do.\n\nKarl Hasselström <kha@treskal.com> writes:\n\n> On 2006-10-26 10:11:50 -0700, Linus Torvalds wrote:\n>\n>> But it's a good rule in general, just because it makes a certain\n>> common workflow explicit. In fact, we really probably should start\n>> to always use the \"refs/remote/origin/HEAD\" kind of syntax by\n>> default, where you can't even _switch_ to the branch maintained in\n>> the remote repository, because it's not a real branch locally.\n>\n> Seconded. I really like having remote branches in their own namespace\n> where I can't confuse them with my local branches by mistake -- and\n> that the branches of different remotes end up in different separate\n> namespaces.\n>\n>> So normally you should consider the \"origin\" branch to be a pointer\n>> to WHAT YOU FETCHED LAST - and that implies that you shouldn't\n>> commit to it, because then it loses that meaning (now it's \"what you\n>> fetched last and then committed your own work on top of\", which is\n>> something totally different).\n>\n> Defaulting to --use-separate-remotes would mean not having to explain\n> this to every single confused new user. :-)\n\nThe only downside that I can think of is that it affects me or\nanybody who works on more than one machine on multiple branches\nslightly negatively.\n\nI know I keep \"master\" checked out on my secondary machines when\nI am done working there, so the mapping origin:master,\nmaint:maint, next:next, and +pu:pu I get by default has been\neasy for me to work on.  With the current layout, updating and\nbuilding four variants can be done with:\n\n\tgit pull\n        for b in master maint next pu\n        do\n        \tgit checkout $b && make || break\n\tdone\n\nwhich is efficient (guaranteed to do only one fetch from remote)\nand convenient.  Also I have Push: mapping set up on my\nmain machine to do master:origin, next:next, maint:maint, and\n+pu:pu so that I can replace the first \"git pull\" on the\nsecondary machine with \"git push secondary\" on my main machine.\n\nWith separate remotes, I'd need something like:\n\n\tfor b in master maint next pu\n        do\n        \tgit checkout $b && git pull && make || break\n\tdone\n\nAnd I also would need to have per-branch configuration to merge\nfrom \". remotes/origin/$b\" without re-fetching while on a\nnon-master branch $b, for the above to work.  I still need to\nremember to process \"master\" first, so all things considered,\nthis is a regression in usability for my workflow.\n\nBut that is probably a minor inconvenience to a minority.  Most\nof the world follow others' repositories that have a single\nprimary head, and defaulting to use separate-remote would help\nthem a lot.\n\nSo I am in favor of the change, but this is not something we can\ndo in a flag-day fashion.  We would probably need updating the\ntutorial and the documentation first.\n\n\n\n\n"},{"id":"298728","messageId":"BAYC1-PASMTP041E1FB36F85221E4E1FB4AEFE0@CEZ.ICE","threadId":"43070","inReplyTo":"7v4pthmew1.fsf@assigned-by-dhcp.cox.net","subject":"Re: git bug? + question","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-11-03T03:45:49Z","receivedAt":"2006-11-03T03:45:49Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 02 Nov 2006 18:40:30 -0800\nJunio C Hamano <junkio@cox.net> wrote:\n\n> which is efficient (guaranteed to do only one fetch from remote)\n> and convenient.  Also I have Push: mapping set up on my\n> main machine to do master:origin, next:next, maint:maint, and\n> +pu:pu so that I can replace the first \"git pull\" on the\n> secondary machine with \"git push secondary\" on my main machine.\n\nOne thing that would make separate-remotes nicer to work with\nis to have an automatic mapping between any local branch and\none of the same name in remotes.\n\nSo for instance, if you have a local branch named pu checked\nout and you pull from origin, remotes/origin/pu would be merged\nafter the fetch unless a manual mapping was defined in the\nremotes or config file.\n\nMaybe even going as far as automatically creating a local branch\nfor each remote branch on clone is worth considering.\n\nOn a peripherally related topic, someone on the xorg list was\ncomplaining that after the initial clone, there is no easy way\nto track branches that get added/deleted from the remote repo.\nIt would be nice if pull had an option to automatically add\nand remove remote branches from the remotes/<remote>/xxx\nnamespace.\n\n"},{"id":"296548","messageId":"20061103074857.GA15972@diana.vm.bytemark.co.uk","threadId":"43070","inReplyTo":"7v4pthmew1.fsf@assigned-by-dhcp.cox.net","subject":"Re: git bug? + question","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-11-03T07:48:57Z","receivedAt":"2006-11-03T07:48:57Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-11-02 18:40:30 -0800, Junio C Hamano wrote:\n\n> which is efficient (guaranteed to do only one fetch from remote) and\n> convenient.\n\nHmm, this is interesting. 99% of the time, I use \"git fetch\", followed\nby \"git pull . remotes/origin/foo\" (often having run gitk in between\nthe two in order to see what's coming). I like to know what I'm\npulling (yes, I know how to undo a bad pull, but still ...).\n\n> And I also would need to have per-branch configuration to merge from\n> \". remotes/origin/$b\" without re-fetching while on a non-master\n> branch $b, for the above to work.\n\nThis is a good point. The \"remotes/$repo/$branch\" names are quite a\nmouthful to type, so default pull sources would be a definite\nimprovement. (It would also be an improvement for the case when the\nuser is susceptible to the human factor.) Simply defaulting to pull\nfrom the branch that this branch was cloned from should do the trick\n(but the pull source should of course be editable).\n\n> I still need to remember to process \"master\" first, so all things\n> considered, this is a regression in usability for my workflow.\n\nWhere does this constraint come from?\n\n> But that is probably a minor inconvenience to a minority.  Most\n> of the world follow others' repositories that have a single\n> primary head, and defaulting to use separate-remote would help\n> them a lot.\n\nI can attest that separate remotes is a usability win also when using\nseveral branches from more than one remote source. It's actually\npossible to infer from the branch name (remotes/$repo/$branch) which\nbranch from which repository is being tracked.\n\nAs an aside, in case of several remote repositories, \"git fetch --all\"\nwould be handy.\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"294391","messageId":"20061103081232.GB15972@diana.vm.bytemark.co.uk","threadId":"43070","inReplyTo":"20061102224549.499610d1.seanlkml@sympatico.ca","subject":"Re: git bug? + question","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-11-03T08:12:32Z","receivedAt":"2006-11-03T08:12:32Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-11-02 22:45:49 -0500, Sean wrote:\n\n> One thing that would make separate-remotes nicer to work with is to\n> have an automatic mapping between any local branch and one of the\n> same name in remotes.\n>\n> So for instance, if you have a local branch named pu checked out and\n> you pull from origin, remotes/origin/pu would be merged after the\n> fetch unless a manual mapping was defined in the remotes or config\n> file.\n\nI would rather see the default pull source of a branch being\ndetermined by which branch it was branched off of. But this should\nmean the same thing in this case. We'd just have to have the heuristic\nthat default pulls from a remotes/*/* branch causes a fetch, while a\ndefault pull from a local branch does not.\n\n> Maybe even going as far as automatically creating a local branch for\n> each remote branch on clone is worth considering.\n\nYes, maybe. It should make for a good default for beginners, at least.\n\n> On a peripherally related topic, someone on the xorg list was\n> complaining that after the initial clone, there is no easy way to\n> track branches that get added/deleted from the remote repo. It would\n> be nice if pull had an option to automatically add and remove remote\n> branches from the remotes/<remote>/xxx namespace.\n\nThat would definitely be useful. But I want it in fetch, not pull. :-)\nWell, I suppose it could be in both.\n\nHmm, I think my dislike of remote pulls can be summed up as: I find it\nconvoluted to have a command that will fetch multiple remote branches,\nthen merge just one of them into my current branch. (I have no problem\nwith pull when the branches to pull are specified explicitly, since in\nthat case they are all merged.) With explicitly specified default pull\nsources it would get better, since then I would know that the correct\nbranch would be merged, but I still don't quite like it.\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"298231","messageId":"7v3b90gbfv.fsf@assigned-by-dhcp.cox.net","threadId":"43070","inReplyTo":"20061103074857.GA15972@diana.vm.bytemark.co.uk","subject":"Re: git bug? + question","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-03T08:51:32Z","receivedAt":"2006-11-03T08:51:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karl Hasselström <kha@treskal.com> writes:\n\n> On 2006-11-02 18:40:30 -0800, Junio C Hamano wrote:\n>\n>> I still need to remember to process \"master\" first, so all things\n>> considered, this is a regression in usability for my workflow.\n>\n> Where does this constraint come from?\n\n    With separate remotes, I'd need something like:\n\n            for b in master maint next pu\n            do\n                    git checkout $b && git pull && make || break\n            done\n\n    And I also would need to have per-branch configuration to merge\n    from \". remotes/origin/$b\" without re-fetching while on a\n    non-master branch $b, for the above to work.  I still need to\n    remember to process \"master\" first, so all things considered,\n    this is a regression in usability for my workflow.\n\nBecause I'll have to have the per-branch configuration that\nwould say something like this:\n\n\t[remote.\"gitster\"]\n\t\turl = gitster.example.com:/home/junio/git.git/\n        \tfetch = heads/maint:remotes/gitster/maint\n        \tfetch = heads/master:remotes/gitster/master\n        \tfetch = heads/next:remotes/gitster/next\n        \tfetch = +heads/pu:remotes/gitster/pu\n\n\t[branch.\"master\"]\n        \tremote = gitster\n                merge = heads/master\n\t[branch.\"maint\"]\n        \tremote = .\n                merge = remotes/gitster/maint\n\t[branch.\"next\"]\n        \tremote = .\n                merge = remotes/gitster/next\n\t...\n\nSide note: the above would not actually work because I am\nmissing an earlier patch by Santi to special case 'dot' as the\nvalue of \"branch.$name.remote\", but I think you get the idea.\n\nThis requires that by the time we update maint, next and pu\nbranches with what is in the upstream, their corresponding\nremotes/gitster/* branches are already up-to-date and do not\nhave to be re-fetched, and processing master first is what\nguarantees it.\n\nI do not mind treating \"master\" specially at all; my otherwise\nidle repositories with working tree (read: ones on secondary\nmachines I use primarily to build git binary for that machine or\nthat platform, not to develop on) always have \"master\" checked\nout; I start working in them while \"master\" is checked out, and\nI'll be on \"master\" before I leave that machine.\n\nIf I keep using the traditional layout, where master is fetched\nto origin and next, maint and pu are used to track the remote, I\ndo not have to do any of the above remote/branch configuration\nin the .git/config file, and after one \"git pull\" while on\n\"master\", I'd have all four branches up to date, ready to be\nchecked out and compiled.\n\nBut I suspect this \"following multiple branches at the same\ntime, switch between them only to compile, test and install but\nnever develop on them\" workflow is rather specific to top-level\nmaintainer's workflow and that is why I said defaulting to\nseparate-remote would be an inconvenience to a minority.\n"},{"id":"296903","messageId":"200611030853.26467.andyparkins@gmail.com","threadId":"43070","inReplyTo":"20061103074857.GA15972@diana.vm.bytemark.co.uk","subject":"Re: git bug? + question","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-03T08:53:25Z","receivedAt":"2006-11-03T08:53:25Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2006 November 03 07:48, Karl Hasselström wrote:\n\n> Hmm, this is interesting. 99% of the time, I use \"git fetch\", followed\n> by \"git pull . remotes/origin/foo\" (often having run gitk in between\n\nI often do this too; and have found that the \"remotes\" is not needed provided \nthere is no overlap with your local branch names.  The above can be replaced \nwith\n\n  git pull . origin/foo\n\nThis relies on there being no \"origin/foo\" local branch.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"296808","messageId":"200611030909.02564.andyparkins@gmail.com","threadId":"43070","inReplyTo":"7v3b90gbfv.fsf@assigned-by-dhcp.cox.net","subject":"Re: git bug? + question","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-03T09:09:00Z","receivedAt":"2006-11-03T09:09:00Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2006 November 03 08:51, Junio C Hamano wrote:\n\n> time, switch between them only to compile, test and install but\n> never develop on them\" workflow is rather specific to top-level\n> maintainer's workflow and that is why I said defaulting to\n> separate-remote would be an inconvenience to a minority.\n\nThis is only a question of the default; why couldn't you (when it exists) use?\n\n  git clone --dont-use-separate-remote URL\n\nTo get exactly what you always had if that's what you want?\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"294698","messageId":"BAYC1-PASMTP0642BEDA27FC7EADD1A9AAAEFE0@CEZ.ICE","threadId":"43070","inReplyTo":"20061103081232.GB15972@diana.vm.bytemark.co.uk","subject":"Re: git bug? + question","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-11-03T09:25:40Z","receivedAt":"2006-11-03T09:25:40Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Fri, 3 Nov 2006 09:12:32 +0100\nKarl Hasselström <kha@treskal.com> wrote:\n\n> I would rather see the default pull source of a branch being\n> determined by which branch it was branched off of. But this should\n> mean the same thing in this case. We'd just have to have the heuristic\n> that default pulls from a remotes/*/* branch causes a fetch, while a\n> default pull from a local branch does not.\n\nWell, when you create a branch a branch.<branch>.merge entry could be\nautomatically made so that a merge from the proper place happens.\nBut in the absence of any config merge entries, it would be nice to\ndefault to the same branch name from the remote namespace.  This\nremoves the need to create merge entries for the initial clone.\nOf course, currently you have to create branch.<branch>.merge\nentries by hand.\n\n> > On a peripherally related topic, someone on the xorg list was\n> > complaining that after the initial clone, there is no easy way to\n> > track branches that get added/deleted from the remote repo. It would\n> > be nice if pull had an option to automatically add and remove remote\n> > branches from the remotes/<remote>/xxx namespace.\n> \n> That would definitely be useful. But I want it in fetch, not pull. :-)\n> Well, I suppose it could be in both.\n\nYes.\n \n> Hmm, I think my dislike of remote pulls can be summed up as: I find it\n> convoluted to have a command that will fetch multiple remote branches,\n> then merge just one of them into my current branch. (I have no problem\n> with pull when the branches to pull are specified explicitly, since in\n> that case they are all merged.) With explicitly specified default pull\n> sources it would get better, since then I would know that the correct\n> branch would be merged, but I still don't quite like it.\n\nYeah.. Although fetching multiple remotes makes more sense as an\noptimization, especially when using a separate remotes namespace.\nPerhaps the real confusion is created because the only porcelain \nlevel merge command current in Git is \"git pull .\".  A separate\nname might make things easier to grasp.\n\nSean\n"},{"id":"298049","messageId":"20061103094655.GA16721@diana.vm.bytemark.co.uk","threadId":"43070","inReplyTo":"7v3b90gbfv.fsf@assigned-by-dhcp.cox.net","subject":"Re: git bug? + question","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-11-03T09:46:55Z","receivedAt":"2006-11-03T09:46:55Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-11-03 00:51:32 -0800, Junio C Hamano wrote:\n\n> Karl Hasselström <kha@treskal.com> writes:\n>\n> > On 2006-11-02 18:40:30 -0800, Junio C Hamano wrote:\n> >\n> > > I still need to remember to process \"master\" first, so all\n> > > things considered, this is a regression in usability for my\n> > > workflow.\n> >\n> > Where does this constraint come from?\n>\n> Because I'll have to have the per-branch configuration that would\n> say something like this:\n>\n>       [remote.\"gitster\"]\n>               url = gitster.example.com:/home/junio/git.git/\n>               fetch = heads/maint:remotes/gitster/maint\n>               fetch = heads/master:remotes/gitster/master\n>               fetch = heads/next:remotes/gitster/next\n>               fetch = +heads/pu:remotes/gitster/pu\n>\n>       [branch.\"master\"]\n>               remote = gitster\n>               merge = heads/master\n>       [branch.\"maint\"]\n>               remote = .\n>               merge = remotes/gitster/maint\n>       [branch.\"next\"]\n>               remote = .\n>               merge = remotes/gitster/next\n>       ...\n>\n> This requires that by the time we update maint, next and pu branches\n> with what is in the upstream, their corresponding remotes/gitster/*\n> branches are already up-to-date and do not have to be re-fetched,\n> and processing master first is what guarantees it.\n\nAhh, here is where our workflows differ: I would want to have \"remote\n= .\" for all the branches, and use \"git fetch\" to update the remotes.\n(I guess this is only natural; my workflow requires less state in the\nhead of the user, and so is easier for beginners, while yours is\nslightly more efficient in terms of number of commands that have to be\ngiven.)\n\nHmm. How about changing the meaning of \"remote\" slightly? Like this:\n\n      [remote.\"gitster\"]\n              url = gitster.example.com:/home/junio/git.git/\n              fetch = heads/master:remotes/gitster/master\n              fetch = heads/next:remotes/gitster/next\n      [branch.\"master\"]\n              remote = gitster\n              merge = remotes/gitster/master\n      [branch.\"next\"]\n              remote = gitster\n              merge = remotes/gitster/next\n\nThis would mean: When the user says \"git pull\" in master, use the\nremote gitster to fetch updates to remotes/gitster/master, then merge\nremotes/gitster/master into master.\n\nWith this scheme, \"git pull\" would never fetch any other branches than\nthose about to be merged; to fetch more in one go, use \"git fetch\".\n\nI realize this would break existing configs quite badly, so don't take\nit too seriously.\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"293890","messageId":"20061103095106.GB16721@diana.vm.bytemark.co.uk","threadId":"43070","inReplyTo":"20061103042540.192bbd18.seanlkml@sympatico.ca","subject":"Re: git bug? + question","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-11-03T09:51:06Z","receivedAt":"2006-11-03T09:51:06Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-11-03 04:25:40 -0500, Sean wrote:\n\n> Yeah.. Although fetching multiple remotes makes more sense as an\n> optimization, especially when using a separate remotes namespace.\n\nThat's what \"git fetch\" is for. :-)\n\n> Perhaps the real confusion is created because the only porcelain\n> level merge command current in Git is \"git pull .\". A separate name\n> might make things easier to grasp.\n\nIndeed. Having pull = fetch + merge and not having a porcelain merge\ncommand is not good, usability-wise. As is, one _has_ to learn the\nweird ways of pull even if one is only interested in using separate\ncommands to fetch and merge.\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"294277","messageId":"20061103095905.GD7545@admingilde.org","threadId":"43070","inReplyTo":"7v3b90gbfv.fsf@assigned-by-dhcp.cox.net","subject":"Re: git bug? + question","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-11-03T09:59:06Z","receivedAt":"2006-11-03T09:59:06Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Fri, Nov 03, 2006 at 12:51:32AM -0800, Junio C Hamano wrote:\n>     With separate remotes, I'd need something like:\n> \n>             for b in master maint next pu\n>             do\n>                     git checkout $b && git pull && make || break\n>             done\n> \n>     And I also would need to have per-branch configuration to merge\n>     from \". remotes/origin/$b\" without re-fetching while on a\n>     non-master branch $b, for the above to work.  I still need to\n>     remember to process \"master\" first, so all things considered,\n>     this is a regression in usability for my workflow.\n\nyou could also run git-fetch first and then always default to\nthe local repository.  But that would of course make pull just\na shortcut for merge, without any fetch.\n\nWould it be so bad for you to call fetch three times?\nI think the most intuitive thing for pull would be to fetch into\nremotes/<remotename>/* and then to merge\nremotes/<remotename>/<currentbranch>.\n\n-- \nMartin Waitz\n"},{"id":"295447","messageId":"8aa486160611030227w4c79ace9ta00a3eecfc46b11a@mail.gmail.com","threadId":"43070","inReplyTo":"20061103095905.GD7545@admingilde.org","subject":"Re: git bug? + question","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2006-11-03T10:27:36Z","receivedAt":"2006-11-03T10:27:36Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 11/3/06, Martin Waitz <tali@admingilde.org> wrote:\n> I think the most intuitive thing for pull would be to fetch into\n> remotes/<remotename>/* and then to merge\n> remotes/<remotename>/<currentbranch>.\n\nYes as the default branch to merge instead the first line, the problem\nis that it changes the current behaviour. But I think the most\nintuitive thing would be to record the branch it is based off at the\nbranch creation time. Something similar to my patch:\n\nOct 17 [PATCHv2] git-branch: Set branch properties\nMessage-ID: <87y7rf80es.fsf@gmail.com>\n\nNote that it is for the \"old\" git-branch.sh.\n\n"},{"id":"298644","messageId":"Pine.LNX.4.64.0611030741530.25218@g5.osdl.org","threadId":"43070","inReplyTo":"7v3b90gbfv.fsf@assigned-by-dhcp.cox.net","subject":"Re: git bug? + question","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-03T16:10:29Z","receivedAt":"2006-11-03T16:10:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 3 Nov 2006, Junio C Hamano wrote:\n> \n> \t[remote.\"gitster\"]\n\nBtw, why the '.'? It doesn't even work with a dot, you have to have a \nspace, which is also a lot more readable..\n\nAlso, may I suggest that we just extend the format with a robust default \nvalue thing?\n\nIt should be reasonably easy to have just the rule:\n\n - add a new \"remote.<remote>.branch\" thing that lists multiple simple \n   branches separated by whitespace.\n\n - a \"simple branch\" is just a \"implicit refspec\" for the relationship\n   \"heads/<name>:remotes/<remote>/<name>\"\n\nAnd then you should be able to write all of your cumbersome config options \nas a simple\n\n\t[remote \"gitster\"]\n\t\turl = gitster.example.com:/home/junio/git.git/\n\t\tbranch = maint master next +pu\n\nand you're all done. It would imply everything you said.\n\nThis would basically require that \"git-parse-remote\" be re-written as a \nnative builtin, because quite frankly, it would be too damn painful any \nother way, but it really shouldn't be that nasty. In fact, I think we \nshould have done that long ago, because the shell-code is just horrid for \nthings like this.\n\nFor example, for builtin-push (which is currently the only thing that \nparses \"remote\" entries in C), you'd just need to do something like the \nappended..  It would generate the full refspecs from the \"branch\" config \nautomatically.\n\n\t\tLinus\n\n---\ndiff --git a/builtin-push.c b/builtin-push.c\nindex d23974e..805ffa8 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -123,15 +123,33 @@ static int get_remote_config(const char*\n {\n \tif (!strncmp(key, \"remote.\", 7) &&\n \t    !strncmp(key + 7, config_repo, config_repo_len)) {\n-\t\tif (!strcmp(key + 7 + config_repo_len, \".url\")) {\n+\t    \tconst char *subkey = key + 7 + config_repo_len;\n+\t\tif (!strcmp(subkey, \".url\")) {\n \t\t\tif (config_current_uri < MAX_URI)\n \t\t\t\tconfig_uri[config_current_uri++] = xstrdup(value);\n \t\t\telse\n \t\t\t\terror(\"more than %d URL's specified, ignoring the rest\", MAX_URI);\n \t\t}\n-\t\telse if (config_get_refspecs &&\n-\t\t\t !strcmp(key + 7 + config_repo_len, \".push\"))\n-\t\t\tadd_refspec(xstrdup(value));\n+\t\telse if (config_get_refspecs) {\n+\t\t\tif (!strcmp(subkey, \".push\"))\n+\t\t\t\tadd_refspec(xstrdup(value));\n+\t\t\telse if (!strcmp(subkey, \".branch\")) {\n+\t\t\t\twhile (isspace(*value))\n+\t\t\t\t\tvalue++;\n+\t\t\t\twhile (*value) {\n+\t\t\t\t\tconst char *end = value;\n+\t\t\t\t\twhile (!isspace(*end))\n+\t\t\t\t\t\tend++;\n+\t\t\t\t\tadd_refspec(xsprintf(\"heads/%.*s:remotes/%.*s/%.*s\",\n+\t\t\t\t\t\tend-value, value,\n+\t\t\t\t\t\tconfig_repo_len, config_repo,\n+\t\t\t\t\t\tend-value, value));\n+\t\t\t\t\twhile (isspace(*end))\n+\t\t\t\t\t\tend++;\n+\t\t\t\t\tvalue = end;\n+\t\t\t\t}\n+\t\t\t}\n+\t\t}\n \t}\n \treturn 0;\n"},{"id":"297190","messageId":"eiftb1$ild$1@sea.gmane.org","threadId":"43070","inReplyTo":"200611031815.49553.Josef.Weidendorfer@gmx.de","subject":"Re: git bug? + question","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-03T17:13:33Z","receivedAt":"2006-11-03T17:13:33Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Josef Weidendorfer wrote:\n\n> Other option: Introduce \"fetchonly\" line which ignores the original\n> fetch lines in the remote section.\n\nI like this.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296544","messageId":"200611031815.49553.Josef.Weidendorfer@gmx.de","threadId":"43070","inReplyTo":"20061103094655.GA16721@diana.vm.bytemark.co.uk","subject":"Re: git bug? + question","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-03T17:15:49Z","receivedAt":"2006-11-03T17:15:49Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 03 November 2006 10:46, Karl Hasselström wrote:\n> Hmm. How about changing the meaning of \"remote\" slightly? Like this:\n\nThat's not good, as it changes existing config meaning.\nBut why not support fetch lines in [branch.*] sections?\n\nIe. instead of\n\n>       [remote.\"gitster\"]\n>               url = gitster.example.com:/home/junio/git.git/\n>               fetch = heads/master:remotes/gitster/master\n>               fetch = heads/next:remotes/gitster/next\n>       [branch.\"master\"]\n>               remote = gitster\n>               merge = remotes/gitster/master\n>       [branch.\"next\"]\n>               remote = gitster\n>               merge = remotes/gitster/next\n\nmake your config look like\n\n       [remote.\"gitster\"]\n               url = gitster.example.com:/home/junio/git.git/\n       [branch.\"master\"]\n               remote = gitster\n               fetch = heads/master:remotes/gitster/master\n               merge = remotes/gitster/master\n       [branch.\"next\"]\n               remote = gitster\n               fetch = heads/next:remotes/gitster/next\n               merge = remotes/gitster/next\n\nA fetch line in [branch.*] means: Also fetch this refspec in\naddition to the refspecs specified in the remote section.\nProblem being that \"git fetch gitster\" does nothing anymore :-(\n\nOther option: Introduce \"fetchonly\" line which ignores the original\nfetch lines in the remote section.\n\n       [remote.\"gitster\"]\n               url = gitster.example.com:/home/junio/git.git/\n               fetch = heads/master:remotes/gitster/master\n               fetch = heads/next:remotes/gitster/next\n       [branch.\"master\"]\n               remote = gitster\n               fetchonly = heads/master:remotes/gitster/master\n               merge = remotes/gitster/master\n\n"},{"id":"294598","messageId":"200611032006.26337.Josef.Weidendorfer@gmx.de","threadId":"43070","inReplyTo":"eiftb1$ild$1@sea.gmane.org","subject":"Re: git bug? + question","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-03T19:06:26Z","receivedAt":"2006-11-03T19:06:26Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 03 November 2006 18:13, Jakub Narebski wrote:\n> Josef Weidendorfer wrote:\n> \n> > Other option: Introduce \"fetchonly\" line which ignores the original\n> > fetch lines in the remote section.\n> \n> I like this.\n\nThat's implementing it:\n\n=================================\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -156,6 +156,18 @@ canon_refs_list_for_fetch () {\n\n # Returns list of src: (no store), or src:dst (store)\n get_remote_default_refs_for_fetch () {\n+       # if there are any branch.${curr_branch}.fetchonly entries,\n+       # only use them as default\n+       curr_branch=$(git-symbolic-ref HEAD | \\\n+               sed -e 's|^refs/heads/||')\n+       fetchonly_branches=$(git-repo-config \\\n+               --get-all \"branch.${curr_branch}.fetchonly\")\n+       if test ! -z $fetchonly_branches\n+       then\n+               canon_refs_list_for_fetch -d \"$1\" $fetchonly_branches\n+               return\n+       fi\n+\n        data_source=$(get_data_source \"$1\")\n        case \"$data_source\" in\n        '' | config-partial | branches-partial)\n=================================\n\nThe problem with this small patch is that with\n\n       [remote.\"gitster\"]\n               url = gitster.example.com:/home/junio/git.git/\n               fetch = heads/master:remotes/gitster/master\n               fetch = heads/next:remotes/gitster/next\n       [branch.\"master\"]\n               remote = gitster\n               fetchonly = heads/master:remotes/gitster/master\n               merge = remotes/gitster/master\n\nand current branch \"master\", even \"git fetch gitster\" does not\nfetch both branches, which is expected IMHO. We would need to\npass the info that an explicit repository was given down to\nget_remote_default_refs_for_fetch().\n\n"},{"id":"293807","messageId":"7vvelw72is.fsf@assigned-by-dhcp.cox.net","threadId":"43070","inReplyTo":"200611030909.02564.andyparkins@gmail.com","subject":"Re: git bug? + question","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-03T19:28:59Z","receivedAt":"2006-11-03T19:28:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> writes:\n\n> On Friday 2006 November 03 08:51, Junio C Hamano wrote:\n>\n>> time, switch between them only to compile, test and install but\n>> never develop on them\" workflow is rather specific to top-level\n>> maintainer's workflow and that is why I said defaulting to\n>> separate-remote would be an inconvenience to a minority.\n>\n> This is only a question of the default; why couldn't you (when\n> it exists) use?\n>\n>   git clone --dont-use-separate-remote URL\n\nBecause I do not need it ;-).  If we switch the default to\nseparate-remote, I'd just let clone to lay it out that way and\nthen update the ref layout myself to suit my needs.  So it is\nreally just the matter of deciding which is more appropriate\ndefault for the majority.\n"},{"id":"297128","messageId":"7v7iyc71dt.fsf@assigned-by-dhcp.cox.net","threadId":"43070","inReplyTo":"Pine.LNX.4.64.0611030741530.25218@g5.osdl.org","subject":"Re: git bug? + question","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-03T19:53:34Z","receivedAt":"2006-11-03T19:53:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> On Fri, 3 Nov 2006, Junio C Hamano wrote:\n>> \n>> \t[remote.\"gitster\"]\n>\n> Btw, why the '.'? It doesn't even work with a dot, you have to have a \n> space, which is also a lot more readable..\n\nUntested example ;-).\n\nI do not have to use any of these in real life because I work in\nrepositories laid out without separate remotes.\n\n> This would basically require that \"git-parse-remote\" be re-written as a \n> native builtin, because quite frankly, it would be too damn painful any \n> other way, but it really shouldn't be that nasty. In fact, I think we \n> should have done that long ago, because the shell-code is just horrid for \n> things like this.\n\nI agree.\n\nI am rediscovering git-cvsimport and git-cvsexportcommit right\nnow, and one thing I wished was git-cvsimport to have worked as\nif it is a git-fetch of an exotic flavor.  Integrating it into\ngit-fetch so that \"URL: cvs://repo.si.to/ry\" in .git/remotes\nwould do a sensible thing and make git-cvsimport honor\n\"Pull: HEAD:remotes/cvs/master\" would both need some work in\nparse-remote, and doing anything more complicated than the\ncurrent parse-remote in shell is quite painful.\n"},{"id":"297194","messageId":"20061103202945.GA7585@spearce.org","threadId":"43070","inReplyTo":"20061103042540.192bbd18.seanlkml@sympatico.ca","subject":"Re: git bug? + question","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-03T20:29:45Z","receivedAt":"2006-11-03T20:29:45Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sean <seanlkml@sympatico.ca> wrote:\n> On Fri, 3 Nov 2006 09:12:32 +0100\n> Karl Hasselström <kha@treskal.com> wrote:\n> \n> > I would rather see the default pull source of a branch being\n> > determined by which branch it was branched off of. But this should\n> > mean the same thing in this case. We'd just have to have the heuristic\n> > that default pulls from a remotes/*/* branch causes a fetch, while a\n> > default pull from a local branch does not.\n> \n> Well, when you create a branch a branch.<branch>.merge entry could be\n> automatically made so that a merge from the proper place happens.\n\nYes, definately.  For most people I know that use Git the branch\nthey branched off of is the one they need to pull in on a regular\nbasis to keep their topic branch current.  They rarely pull other\nbranches in.\n\n> But in the absence of any config merge entries, it would be nice to\n> default to the same branch name from the remote namespace.  This\n> removes the need to create merge entries for the initial clone.\n> Of course, currently you have to create branch.<branch>.merge\n> entries by hand.\n\nNack.  I'd rather see the entries added/removed from .git/config when\nthe branch is created/deleted, just like the ref and the reflog are\ncreated/deleted.  It makes behavior more consistent for the user\nand it is mostly self documenting...\n\n\t\"why is branch FOO pulling FOO by default?  ahhh, its in\n\t.git/config after git branch FOO FOO.\"\n\nSame goes for git-clone.  The branch.master.merge=origin/master\nentry should be in .git/config file after the clone is complete.\n\n-- \n"},{"id":"293904","messageId":"20061103203610.GB7585@spearce.org","threadId":"43070","inReplyTo":"20061102224549.499610d1.seanlkml@sympatico.ca","subject":"Re: git bug? + question","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-03T20:36:10Z","receivedAt":"2006-11-03T20:36:10Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sean <seanlkml@sympatico.ca> wrote:\n> On Thu, 02 Nov 2006 18:40:30 -0800\n> Junio C Hamano <junkio@cox.net> wrote:\n> \n> > which is efficient (guaranteed to do only one fetch from remote)\n> > and convenient.  Also I have Push: mapping set up on my\n> > main machine to do master:origin, next:next, maint:maint, and\n> > +pu:pu so that I can replace the first \"git pull\" on the\n> > secondary machine with \"git push secondary\" on my main machine.\n> \n> One thing that would make separate-remotes nicer to work with\n> is to have an automatic mapping between any local branch and\n> one of the same name in remotes.\n> \n> So for instance, if you have a local branch named pu checked\n> out and you pull from origin, remotes/origin/pu would be merged\n> after the fetch unless a manual mapping was defined in the\n> remotes or config file.\n> \n> Maybe even going as far as automatically creating a local branch\n> for each remote branch on clone is worth considering.\n\nNack.\n\nI work with a workflow where our central repository has 2 important\nbranches (vmtip and vmvt), and a bunch of transient developer\ntopic branches (e.g. sp/foo).  We only have a master branch in this\nrepository so that git-clone will clone it without choking during\nthe clone.  Users tend to do immediately after a clone:\n\n\tgit branch -D master\n\tgit branch -D origin\n\tgit branch -D ... other topic branches not interested in ...\n\tedit .git/remotes/origin ... delete topic branches ...\n\nWhy?  Because vmtip and vmdvt have meaning to these users, much as\npu has meaning.  Really vmtip is roughly equal to master in Git and\nvmdvt is roughly equal to maint but not having the mental mapping of\n\"vmtip == master\" just makes things easier.\n\nCreating a local branch for every remote branch would just make\nthings worse in the above workflow; not to mention it makes it\nconfusing for other users who might be fetching into a repository\nand expecting their local \"next\" to to update automatically after\na fetch...\n \n> On a peripherally related topic, someone on the xorg list was\n> complaining that after the initial clone, there is no easy way\n> to track branches that get added/deleted from the remote repo.\n> It would be nice if pull had an option to automatically add\n> and remove remote branches from the remotes/<remote>/xxx\n> namespace.\n\nOr at least deleting/skipping over a branch you listed to fetch\nfrom the remote that no longer happnes to be on the remote.  This is\ncausing some pain due to the topic branches noted above.\n\n-- \n"},{"id":"295740","messageId":"BAYC1-PASMTP01F45766D9195AAFD81789AEFE0@CEZ.ICE","threadId":"43070","inReplyTo":"20061103203610.GB7585@spearce.org","subject":"Re: git bug? + question","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-11-03T21:24:22Z","receivedAt":"2006-11-03T21:24:22Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Fri, 3 Nov 2006 15:36:10 -0500\nShawn Pearce <spearce@spearce.org> wrote:\n\n> > Maybe even going as far as automatically creating a local branch\n> > for each remote branch on clone is worth considering.\n> \n> Nack.\n> \n> I work with a workflow where our central repository has 2 important\n> branches (vmtip and vmvt), and a bunch of transient developer\n> topic branches (e.g. sp/foo).  We only have a master branch in this\n> repository so that git-clone will clone it without choking during\n> the clone.  Users tend to do immediately after a clone:\n> \n> \tgit branch -D master\n> \tgit branch -D origin\n> \tgit branch -D ... other topic branches not interested in ...\n> \tedit .git/remotes/origin ... delete topic branches ...\n\nI think your Nack was a little rash here.  The feature would be quite\nuseful to work flows other than yours.  It sounds like what _you_ want\nis a feature to select branches when cloning rather than the current\ndefault of cloning all.  That would stop your developers having to \ndelete branches and editing .git/remotes/origin immediately\nafter cloning.\n\n"},{"id":"296250","messageId":"BAYC1-PASMTP020F825A42FB7A7DB6CD8BAEFE0@CEZ.ICE","threadId":"43070","inReplyTo":"20061103202945.GA7585@spearce.org","subject":"Re: git bug? + question","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-11-03T21:27:07Z","receivedAt":"2006-11-03T21:27:07Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Fri, 3 Nov 2006 15:29:45 -0500\nShawn Pearce <spearce@spearce.org> wrote:\n\n> Nack.  I'd rather see the entries added/removed from .git/config when\n> the branch is created/deleted, just like the ref and the reflog are\n> created/deleted.  It makes behavior more consistent for the user\n> and it is mostly self documenting...\n> \n> \t\"why is branch FOO pulling FOO by default?  ahhh, its in\n> \t.git/config after git branch FOO FOO.\"\n> \n> Same goes for git-clone.  The branch.master.merge=origin/master\n> entry should be in .git/config file after the clone is complete.\n\nWell that's certainly an alternative implementation that achieves \nthe same thing.  The essential point is that most of the time the\nGit user should not have to manually create the merge entries\nin the config file.  Git should be smart enough to get it right\nmost of the time automatically.\n\n"},{"id":"294399","messageId":"20061103232936.GC6970@coredump.intra.peff.net","threadId":"43070","inReplyTo":"20061103202945.GA7585@spearce.org","subject":"Re: git bug? + question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-11-03T23:29:36Z","receivedAt":"2006-11-03T23:29:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 03, 2006 at 03:29:45PM -0500, Shawn Pearce wrote:\n\n> Nack.  I'd rather see the entries added/removed from .git/config when\n> the branch is created/deleted, just like the ref and the reflog are\n> created/deleted.  It makes behavior more consistent for the user\n> and it is mostly self documenting...\n\nIf we go this route, please consider updating .git/auto-branch-config or\nsimilar, and adding the functionality to include that file into\n.git/config.\n\nI think the concept of automagically munging a user-editable config file\nis problematic, especially when users might manage those files with\nversion control or other systems.\n\n"},{"id":"297936","messageId":"20061104050305.GA9003@spearce.org","threadId":"43070","inReplyTo":"20061103162422.b0bf105e.seanlkml@sympatico.ca","subject":"Re: git bug? + question","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-04T05:03:06Z","receivedAt":"2006-11-04T05:03:06Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sean <seanlkml@sympatico.ca> wrote:\n> On Fri, 3 Nov 2006 15:36:10 -0500\n> Shawn Pearce <spearce@spearce.org> wrote:\n> \n> > > Maybe even going as far as automatically creating a local branch\n> > > for each remote branch on clone is worth considering.\n> > \n> > Nack.\n> > \n> > I work with a workflow where our central repository has 2 important\n> > branches (vmtip and vmvt), and a bunch of transient developer\n> > topic branches (e.g. sp/foo).  We only have a master branch in this\n> > repository so that git-clone will clone it without choking during\n> > the clone.  Users tend to do immediately after a clone:\n> > \n> > \tgit branch -D master\n> > \tgit branch -D origin\n> > \tgit branch -D ... other topic branches not interested in ...\n> > \tedit .git/remotes/origin ... delete topic branches ...\n> \n> I think your Nack was a little rash here.  The feature would be quite\n> useful to work flows other than yours.  It sounds like what _you_ want\n> is a feature to select branches when cloning rather than the current\n> default of cloning all.  That would stop your developers having to \n> delete branches and editing .git/remotes/origin immediately\n> after cloning.\n\nAfter reading your reply you are probably correct.  I can see there\nmay be workflows that want every remote branch also created as a\nlocal branch.\n\nI could certainly live with a command line option to clone, e.g.:\n\n\tgit clone --only vmdvt,vmtip user@host:/path...\n\nSo yes, my 'Nack' may have been a little too rash.\n\n-- \n"},{"id":"297103","messageId":"20061104050402.GB9003@spearce.org","threadId":"43070","inReplyTo":"20061103162707.cc8af608.seanlkml@sympatico.ca","subject":"Re: git bug? + question","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-04T05:04:02Z","receivedAt":"2006-11-04T05:04:02Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sean <seanlkml@sympatico.ca> wrote:\n> On Fri, 3 Nov 2006 15:29:45 -0500\n> Shawn Pearce <spearce@spearce.org> wrote:\n> \n> > Nack.  I'd rather see the entries added/removed from .git/config when\n> > the branch is created/deleted, just like the ref and the reflog are\n> > created/deleted.  It makes behavior more consistent for the user\n> > and it is mostly self documenting...\n> > \n> > \t\"why is branch FOO pulling FOO by default?  ahhh, its in\n> > \t.git/config after git branch FOO FOO.\"\n> > \n> > Same goes for git-clone.  The branch.master.merge=origin/master\n> > entry should be in .git/config file after the clone is complete.\n> \n> Well that's certainly an alternative implementation that achieves \n> the same thing.  The essential point is that most of the time the\n> Git user should not have to manually create the merge entries\n> in the config file.  Git should be smart enough to get it right\n> most of the time automatically.\n\nAgreed completely.  At least though with repo-config we have a\ncommand line tool which users/scripts alike can use to read/edit\nthe configuration of a \"remote\"; .git/remotes/ has no such tool.\n\n-- \n"},{"id":"293882","messageId":"20061104051008.GC9003@spearce.org","threadId":"43070","inReplyTo":"20061103232936.GC6970@coredump.intra.peff.net","subject":"Re: git bug? + question","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-04T05:10:08Z","receivedAt":"2006-11-04T05:10:08Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jeff King <peff@peff.net> wrote:\n> On Fri, Nov 03, 2006 at 03:29:45PM -0500, Shawn Pearce wrote:\n> \n> > Nack.  I'd rather see the entries added/removed from .git/config when\n> > the branch is created/deleted, just like the ref and the reflog are\n> > created/deleted.  It makes behavior more consistent for the user\n> > and it is mostly self documenting...\n> \n> If we go this route, please consider updating .git/auto-branch-config or\n> similar, and adding the functionality to include that file into\n> .git/config.\n> \n> I think the concept of automagically munging a user-editable config file\n> is problematic, especially when users might manage those files with\n> version control or other systems.\n\nMost users that I know use repo-config to munge their .git/config\nrather than editing it by hand.  Though with more data stored in\nit for branches and remotes that is probably going to change.\n\nIf we go this route I wonder if want to say create a config file\nper branch and then use a wildcard include like Apache's httpd.conf\nwildcard include, e.g.:\n\n\t.git/config:\n\t\tinclude branch_configs/**/*.config\n\n\t.git/branch_configs/refs/heads/master.config:\n\t\t[branch \"master\"]\n\t\t\t...\n\nAs then git-branch is only manipulating one file per branch.\n\n-- \n"},{"id":"294453","messageId":"7vk62bxvtx.fsf@assigned-by-dhcp.cox.net","threadId":"43070","inReplyTo":"200611031815.49553.Josef.Weidendorfer@gmx.de","subject":"Re: git bug? + question","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-04T12:03:38Z","receivedAt":"2006-11-04T12:03:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n\n> On Friday 03 November 2006 10:46, Karl Hasselström wrote:\n>> Hmm. How about changing the meaning of \"remote\" slightly? Like this:\n>\n> That's not good, as it changes existing config meaning.\n>...\n> Other option: Introduce \"fetchonly\" line which ignores the original\n> fetch lines in the remote section.\n>\n>        [remote.\"gitster\"]\n>                url = gitster.example.com:/home/junio/git.git/\n>                fetch = heads/master:remotes/gitster/master\n>                fetch = heads/next:remotes/gitster/next\n>        [branch.\"master\"]\n>                remote = gitster\n>                fetchonly = heads/master:remotes/gitster/master\n>                merge = remotes/gitster/master\n\nThat is a regression in that now I need to fetch twice (in the\nabove example, in reality four).\n\n"},{"id":"296177","messageId":"7vejsjxvtw.fsf@assigned-by-dhcp.cox.net","threadId":"43070","inReplyTo":"BAYC1-PASMTP01F45766D9195AAFD81789AEFE0@CEZ.ICE","subject":"Re: git bug? + question","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-04T12:03:39Z","receivedAt":"2006-11-04T12:03:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sean <seanlkml@sympatico.ca> writes:\n\n> I think your Nack was a little rash here.  The feature would be quite\n> useful to work flows other than yours.  It sounds like what _you_ want\n> is a feature to select branches when cloning rather than the current\n> default of cloning all.  That would stop your developers having to \n> delete branches and editing .git/remotes/origin immediately\n> after cloning.\n\nI think this conversation demonstrates that this previous\nstatement of yours was also rather rash:\n\n  The essential point is that most of the time the Git user\n  should not have to manually create the merge entries in the\n  config file.  Git should be smart enough to get it right most\n  of the time automatically.\n\nThere is no \"get it right most of the time\" that would apply to\nevery workflow.  We should just admit that no default layout and\nconfiguration would suit everybody's needs.  What we should do\nis to try to capture a handful useful patterns and make it easy\nfor people to apply those canned patterns.\n\nFor example, that is what we did for \"git clone\".  We identified\ntwo common layouts, traditional and separate-remote, and we\nsupport both.  The reason we might want to favor separate-remote\nover traditional should be based on the expected workflow and\nexpertise level of the majority of users.  If a census turns out\nthat the more experienced people tend to prefer traditional\nlayout, then changing the default to separate-remote would be\neasier even if people with workflow separate-remote is more\nappropriate is not the absolute majority, because the layout can\nbe easily changed by more experienced folks.\n\nI think the \"what should the default merge source be\" topic is\nvery similar.  There is no single _right_ way and to some extent\nwhat the vanilla default is does not really matter.\n\n"},{"id":"293975","messageId":"BAYC1-PASMTP0422D580BE471BBCB1EFBDAEFD0@CEZ.ICE","threadId":"43070","inReplyTo":"7vejsjxvtw.fsf@assigned-by-dhcp.cox.net","subject":"Re: git bug? + question","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-11-04T15:33:25Z","receivedAt":"2006-11-04T15:33:25Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 04 Nov 2006 04:03:39 -0800\nJunio C Hamano <junkio@cox.net> wrote:\n\n> There is no \"get it right most of the time\" that would apply to\n> every workflow.  We should just admit that no default layout and\n> configuration would suit everybody's needs.  What we should do\n> is to try to capture a handful useful patterns and make it easy\n> for people to apply those canned patterns.\n\nConsider it admitted ;o)  But there is no need to have just a single\nconfiguration that suits everybody.  For instance, nobody is saying\nto do away with the current default in favor of use-separate-remotes.\nThat is why someone saying \"Nak\" to a feature where all branches\nare checked out locally on clone is \"rash\".  Because it _is_ valuable\nto some workflows.  There is no reason Git could not support it.  If\nit gets in the way of some workflows, then we just make it a\nconfiguration option.  However, I don't feel strongly about this\nparticular option, if you notice in my email I merely suggested it\nfor discussion.\n\nBut by the same token, Git should _better_ support Shawn's example\nworkflow where currently Git makes him delete a bunch of branches\nand edit the remotes/origin file every time after cloning.  It would\nbe rash of me to send out a Nak for such an improvement just because\nI don't need that feature.\n\nAll that remains is coming to some consensus on which set of options\nshould be enabled for new Git users.  Once someone is up to speed, they\ncan enable whichever options support their workflow.  But once they've\nenabled those options, Git should do it's best to support that workflow\nwithout a lot of manual intervention most of the time.  That's what\nthe options I was suggesting would do for some workflows.\n\n"},{"id":"296390","messageId":"200611041850.20136.Josef.Weidendorfer@gmx.de","threadId":"43070","inReplyTo":"7vk62bxvtx.fsf@assigned-by-dhcp.cox.net","subject":"Re: git bug? + question","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-04T17:50:19Z","receivedAt":"2006-11-04T17:50:19Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Saturday 04 November 2006 13:03, Junio C Hamano wrote:\n> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n> \n> > On Friday 03 November 2006 10:46, Karl Hasselström wrote:\n> >> Hmm. How about changing the meaning of \"remote\" slightly? Like this:\n> >\n> > That's not good, as it changes existing config meaning.\n> >...\n> > Other option: Introduce \"fetchonly\" line which ignores the original\n> > fetch lines in the remote section.\n> >\n> >        [remote.\"gitster\"]\n> >                url = gitster.example.com:/home/junio/git.git/\n> >                fetch = heads/master:remotes/gitster/master\n> >                fetch = heads/next:remotes/gitster/next\n> >        [branch.\"master\"]\n> >                remote = gitster\n> >                fetchonly = heads/master:remotes/gitster/master\n> >                merge = remotes/gitster/master\n> \n> That is a regression in that now I need to fetch twice (in the\n> above example, in reality four).\n\nHmm. You do not need to use it.\nHowever, there are use cases for this.\n\nFor example, I am mostly interested in what's new on the\nnext and master branch in the git repository. There is no need for me\nto always fetch pu or maint.\n\nSo I can use (I am behind a firewall):\n\n[remote \"origin\"]\n        url = http://www.kernel.org/pub/scm/git/git.git\n        fetch = master:origin\n        fetch = maint:maint\n        fetch = next:next\n        fetch = todo:todo\n        fetch = +pu:pu\n\n[branch \"master\"]\n        remote = origin\n        fetchonly = master:origin\n\tfetchonly = next:next\n        merge = origin\n\nand get master and next with a \"git fetch\" when on master, and\n\"git fetch origin\" would fetch all branches.\n\n"},{"id":"296286","messageId":"200611041852.23867.Josef.Weidendorfer@gmx.de","threadId":"43070","inReplyTo":"20061104050305.GA9003@spearce.org","subject":"Re: git bug? + question","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-04T17:52:23Z","receivedAt":"2006-11-04T17:52:23Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Saturday 04 November 2006 06:03, Shawn Pearce wrote:\n> After reading your reply you are probably correct.  I can see there\n> may be workflows that want every remote branch also created as a\n> local branch.\n> \n> I could certainly live with a command line option to clone, e.g.:\n> \n> \tgit clone --only vmdvt,vmtip user@host:/path...\n\nStill missing here: What branch should be checked out after\ncloning?\n\nPerhaps it is better to extend git-checkout to allow to do the\ncorrect thing when the user specifies a read-only branch from\nrefs/remotes. E.g. with refs/remotes/origin/vmdvt,\n\n \tgit checkout origin/vmdvt\n\nshould create a new local branch refs/heads/vmdvt which forks\nfrom remotes/origin/vmdvt (and abort with\nerror if refs/heads/vmdvt already exists without being the local\ndevelopment branch for remotes/origin/vmdvt), add to .git/config\n\n[branch \"vmdvt\"]\n\tremote = origin\n\tmerge = remotes/origin/vmdvt\n\nand switch to this new created branch.\n\nGiven this addition to git-checkout, the implicit default\naction after cloning with --use-separate-remote should be\n\n\tgit checkout origin/master\n\nwhere \"master\" can be changed on the git-clone command line\nto another branch, e.g. \"--checkout vmdvt\".\n\nIMHO, this addition to git-checkout would make it a lot\neasier to work with --use-separate-remote, as there,\nevery branch other the master is read-only.\n\nAnd if you have two remote repositories with a master branch\neach, and you want to develop locally on both, this could\nbe accomplished with\n\n\tgit checkout -b othermaster remotes/otherrepo/master\n\n"},{"id":"293861","messageId":"20061104190512.GA2517@spearce.org","threadId":"43070","inReplyTo":"200611041852.23867.Josef.Weidendorfer@gmx.de","subject":"Re: git bug? + question","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-04T19:05:12Z","receivedAt":"2006-11-04T19:05:12Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:\n> On Saturday 04 November 2006 06:03, Shawn Pearce wrote:\n> > After reading your reply you are probably correct.  I can see there\n> > may be workflows that want every remote branch also created as a\n> > local branch.\n> > \n> > I could certainly live with a command line option to clone, e.g.:\n> > \n> > \tgit clone --only vmdvt,vmtip user@host:/path...\n> \n> Still missing here: What branch should be checked out after\n> cloning?\n\nAh.\n\nI probably should have also stated that my users should be doing\n-n as well with git clone, then using git checkout -b to create\na new branch from one of the refs they did clone.  (Reason is we\nstrictly follow a topic branch model of development, with even the\ndeveloper's local branches beginning with their initials.)\n\nBut you have a good point.  Cloning with say --only as I show above\nmight be confusing as its not defined what branch to checkout after\nthe clone.\n \n> Perhaps it is better to extend git-checkout to allow to do the\n> correct thing when the user specifies a read-only branch from\n> refs/remotes. E.g. with refs/remotes/origin/vmdvt,\n> \n>  \tgit checkout origin/vmdvt\n> \n> should create a new local branch refs/heads/vmdvt which forks\n> from remotes/origin/vmdvt (and abort with\n> error if refs/heads/vmdvt already exists without being the local\n> development branch for remotes/origin/vmdvt)\n\nYes, that would work for our workflow.  I won't try to speak about\nanyone else's.\n\nI'd also say that if the local branch (refs/heads/vmdvt) exists and\nif `git pull . origin/vmdvt` is going to be a fast-forward that the\nfast-forward should happen during the checkout.  That way after the\ncheckout is complete you really do have what is in origin/vmdvt,\nbut are sitting on a local branch.\n\n-- \n"},{"id":"297623","messageId":"20061104190742.GB2517@spearce.org","threadId":"43070","inReplyTo":"20061104103325.bfb5e33e.seanlkml@sympatico.ca","subject":"Re: git bug? + question","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-04T19:07:42Z","receivedAt":"2006-11-04T19:07:42Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sean <seanlkml@sympatico.ca> wrote:\n> All that remains is coming to some consensus on which set of options\n> should be enabled for new Git users.  Once someone is up to speed, they\n> can enable whichever options support their workflow.  But once they've\n> enabled those options, Git should do it's best to support that workflow\n> without a lot of manual intervention most of the time.  That's what\n> the options I was suggesting would do for some workflows.\n\nAgreed.\n\nSince I already have to spell out the entire clone command line\n(including URL) for my users asking them to also include a few\noptions (such as the hypothetical \"--only vmdvt,vmtip -n\") is not\na problem.  As in my workflow could be in the more \"advanced user\"\ncategory.  :-)\n\n-- \n"},{"id":"294213","messageId":"454F0636.1060406@shadowen.org","threadId":"43070","inReplyTo":"200611041852.23867.Josef.Weidendorfer@gmx.de","subject":"Re: git bug? + question","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-06T09:53:58Z","receivedAt":"2006-11-06T09:53:58Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Josef Weidendorfer wrote:\n> On Saturday 04 November 2006 06:03, Shawn Pearce wrote:\n>> After reading your reply you are probably correct.  I can see there\n>> may be workflows that want every remote branch also created as a\n>> local branch.\n>>\n>> I could certainly live with a command line option to clone, e.g.:\n>>\n>> \tgit clone --only vmdvt,vmtip user@host:/path...\n> \n> Still missing here: What branch should be checked out after\n> cloning?\n\nDoes any need to be checked out?  Or perhap I should put it another way,\nwhen we make a virgin repository we default to master checked out but\nits not joined to the DAG.  Perhaps we can just init-db and fetch the\nspecified branches and we are done.  The user will then checkout things\nas they need and if they do not need master they can lose it.\n\n> \n> Perhaps it is better to extend git-checkout to allow to do the\n> correct thing when the user specifies a read-only branch from\n> refs/remotes. E.g. with refs/remotes/origin/vmdvt,\n> \n>  \tgit checkout origin/vmdvt\n> \n> should create a new local branch refs/heads/vmdvt which forks\n> from remotes/origin/vmdvt (and abort with\n> error if refs/heads/vmdvt already exists without being the local\n> development branch for remotes/origin/vmdvt), add to .git/config\n> \n> [branch \"vmdvt\"]\n> \tremote = origin\n> \tmerge = remotes/origin/vmdvt\n> \n> and switch to this new created branch.\n> \n> Given this addition to git-checkout, the implicit default\n> action after cloning with --use-separate-remote should be\n> \n> \tgit checkout origin/master\n> \n> where \"master\" can be changed on the git-clone command line\n> to another branch, e.g. \"--checkout vmdvt\".\n> \n> IMHO, this addition to git-checkout would make it a lot\n> easier to work with --use-separate-remote, as there,\n> every branch other the master is read-only.\n> \n> And if you have two remote repositories with a master branch\n> each, and you want to develop locally on both, this could\n> be accomplished with\n> \n> \tgit checkout -b othermaster remotes/otherrepo/master\n\n-apw\n"},{"id":"296890","messageId":"200611061200.08972.Josef.Weidendorfer@gmx.de","threadId":"43070","inReplyTo":"454F0636.1060406@shadowen.org","subject":"Re: git bug? + question","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-06T11:00:08Z","receivedAt":"2006-11-06T11:00:08Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Monday 06 November 2006 10:53, Andy Whitcroft wrote:\n> Josef Weidendorfer wrote:\n> > On Saturday 04 November 2006 06:03, Shawn Pearce wrote:\n> >> After reading your reply you are probably correct.  I can see there\n> >> may be workflows that want every remote branch also created as a\n> >> local branch.\n> >>\n> >> I could certainly live with a command line option to clone, e.g.:\n> >>\n> >> \tgit clone --only vmdvt,vmtip user@host:/path...\n> > \n> > Still missing here: What branch should be checked out after\n> > cloning?\n> \n> Does any need to be checked out?\n\nWe should not change existing behavior. IMHO, checking out a branch is\nmostly the right thing to do. Of course, you often want to specify which one.\nThe current requirement for a master branch in the origin repository\nis really bad, as it obviously requires ugly workarounds in some cases\n(and totally confuse newbies in such use cases).\n\n> Or perhap I should put it another way, \n> when we make a virgin repository we default to master checked out but\n> its not joined to the DAG.\n\nI do not understand this. By creating a local branch, the commit DAG\nis never changed.\n\n"},{"id":"294939","messageId":"200611061205.42062.Josef.Weidendorfer@gmx.de","threadId":"43070","inReplyTo":"20061104190512.GA2517@spearce.org","subject":"Re: git bug? + question","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-06T11:05:41Z","receivedAt":"2006-11-06T11:05:41Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Saturday 04 November 2006 20:05, Shawn Pearce wrote:\n> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:\n> >\n> >  \tgit checkout origin/vmdvt\n> > \n> > should create a new local branch refs/heads/vmdvt which forks\n> > from remotes/origin/vmdvt (and abort with\n> > error if refs/heads/vmdvt already exists without being the local\n> > development branch for remotes/origin/vmdvt)\n> \n> Yes, that would work for our workflow.  I won't try to speak about\n> anyone else's.\n> \n> I'd also say that if the local branch (refs/heads/vmdvt) exists and\n> if `git pull . origin/vmdvt` is going to be a fast-forward that the\n> fast-forward should happen during the checkout.  That way after the\n> checkout is complete you really do have what is in origin/vmdvt,\n> but are sitting on a local branch.\n\nHmmm... But you are changing the tip of a local development branch,\nwhich is probably not always the thing we want.\n\nThinking about it, we should always error out if a proposed branch\nname for a read-only branch already exists.\n\nJosef\n\n"},{"id":"295091","messageId":"454F2B5B.8090405@shadowen.org","threadId":"43070","inReplyTo":"200611061200.08972.Josef.Weidendorfer@gmx.de","subject":"Re: git bug? + question","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-06T12:32:27Z","receivedAt":"2006-11-06T12:32:27Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Josef Weidendorfer wrote:\n> On Monday 06 November 2006 10:53, Andy Whitcroft wrote:\n>> Josef Weidendorfer wrote:\n>>> On Saturday 04 November 2006 06:03, Shawn Pearce wrote:\n>>>> After reading your reply you are probably correct.  I can see there\n>>>> may be workflows that want every remote branch also created as a\n>>>> local branch.\n>>>>\n>>>> I could certainly live with a command line option to clone, e.g.:\n>>>>\n>>>> \tgit clone --only vmdvt,vmtip user@host:/path...\n>>> Still missing here: What branch should be checked out after\n>>> cloning?\n>> Does any need to be checked out?\n> \n> We should not change existing behavior. IMHO, checking out a branch is\n> mostly the right thing to do. Of course, you often want to specify which one.\n> The current requirement for a master branch in the origin repository\n> is really bad, as it obviously requires ugly workarounds in some cases\n> (and totally confuse newbies in such use cases).\n\nWe are not changing existing behaviour, if we do not check anything out\nonly when specifying '--only'.\n> \n>> Or perhap I should put it another way, \n>> when we make a virgin repository we default to master checked out but\n>> its not joined to the DAG.\n> \n> I do not understand this. By creating a local branch, the commit DAG\n> is never changed.\n\nIn a virgin repository there is no DAG to speak of and master doesn't\nreally point anywhere until the first commit.  I was proposing that when\n--only is specified, we just leave things as they are.  The master half\npointing into the zero element DAG we have in an entirely empty repo.\nThe new unconnected DAG or DAG's we have downloaded in the clone will be\nattached to their respective branch names.\n\n"}]}