{"thread":{"id":"6238","subject":"New way of tracking remote branches -- question","startedAt":"2007-01-05T23:02:31Z","lastAt":"2007-01-09T08:57:09Z","messageCount":13,"participants":["Luben Tuikov","Junio C Hamano","Steven Grimm","Theodore Tso","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30922","messageId":"776323.21089.qm@web31808.mail.mud.yahoo.com","threadId":"6238","inReplyTo":null,"subject":"New way of tracking remote branches -- question","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-05T23:02:31Z","receivedAt":"2007-01-05T23:02:31Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"I can see that the remote heads are where they are supposed to be\nbut no local tracking heads are created (by default). I had\nto do this manually.\n\nOld behavior was that git did that for you automatically.\nSo I suppose this is another newbie protection.\n\nWhat is the now the new, accepted way of tracking locally\nremote branches? (other than creating them manually in\nrefs/heads?)\n\nThanks,\n Luben\n"},{"id":"30926","messageId":"7vzm8xcbcp.fsf@assigned-by-dhcp.cox.net","threadId":"6238","inReplyTo":"776323.21089.qm@web31808.mail.mud.yahoo.com","subject":"Re: New way of tracking remote branches -- question","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-05T23:17:26Z","receivedAt":"2007-01-05T23:17:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> I can see that the remote heads are where they are supposed to be\n> but no local tracking heads are created (by default). I had\n> to do this manually.\n>\n> Old behavior was that git did that for you automatically.\n> So I suppose this is another newbie protection.\n\nA very fuzzily stated question which is hard to answer, but I do\nnot think it is another newbie protection, if it apparently is\nactively hurting you. Also the documentation may need to be\nupdated to teach you enough about how to achieve what you want.\n\nYou can see where remote heads are by doing what? ls-remote?\n\"Old behaviour\" for what configuration?\n\nA fresh clone made with a recent version sets things up to track\nall remote branches from the repository you cloned from under\nremotes/origin/, and it even tracks new ones as they are added\nat the remote, so you probably are doing something different\nfrom the default configuration that has:\n\n remotes.origin.fetch = +refs/heads/*:refs/remotes/origin/*\n"},{"id":"30931","messageId":"7vmz4xcacr.fsf@assigned-by-dhcp.cox.net","threadId":"6238","inReplyTo":"7vzm8xcbcp.fsf@assigned-by-dhcp.cox.net","subject":"Re: New way of tracking remote branches -- question","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-05T23:39:00Z","receivedAt":"2007-01-05T23:39:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Luben Tuikov writes:\n>\n>> I can see that the remote heads are where they are supposed to be\n>> but no local tracking heads are created (by default). I had\n>> to do this manually.\n>>\n>> Old behavior was that git did that for you automatically.\n>> So I suppose this is another newbie protection.\n>\n> A very fuzzily stated question which is hard to answer, but I do\n> not think it is another newbie protection, if it apparently is\n> actively hurting you. Also the documentation may need to be\n> updated to teach you enough about how to achieve what you want.\n\nCan you state the problem you observed about the recent git in a\nway that is easier to debug?\n\nFor example, you could state:\n\n\tWith older git (I verified that v1.3.0 still works like\n\tthis), I used to be able to just say:\n\n\t\t$ git fetch\n\n\t(this is the exact command line -- I am not giving a URL\n\tnor even \"origin\" after \"git fetch\"). When the upstream\n\tcreated a new branch 'blah', the above command created a\n\tnew local branch 'blah' automatically for me. With the\n\ttip of 'master' (e27e609), this does not happen anymore.\n\n\tMy configuration is that I have .git/remotes/origin file\n\twhose contents is .... I do not have any remote.*.url,\n\tremote.*.fetch, nor branch.*.remote configuration variables.\n\nto be more helpful.\n\nI am not dismissing your message as whining. You probably have\nhit a regression while we adopted the BCP to encourage separate\nremote layout, and I would like to understand the issue.\n"},{"id":"30933","messageId":"7vejq9c9tf.fsf@assigned-by-dhcp.cox.net","threadId":"6238","inReplyTo":"776323.21089.qm@web31808.mail.mud.yahoo.com","subject":"Re: New way of tracking remote branches -- question","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-05T23:50:36Z","receivedAt":"2007-01-05T23:50:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> I can see that the remote heads are where they are supposed to be\n> but no local tracking heads are created (by default). I had\n> to do this manually.\n\nAh, after firing off a few messages, I think I now guessed\nwhat you are talking about correctly.\n\nYou are talking about the separate remote layout \"git clone\"\ncreates, and talking about the fact that there is nothing in\nrefs/heads/ except master while refs/remotes/origin/ mirrors\nwhat the remote side has faithfully, aren't you?\n\nIf that is the case, I can explain. It is a good topic to talk\nabout.\n"},{"id":"30939","messageId":"224619.92262.qm@web31810.mail.mud.yahoo.com","threadId":"6238","inReplyTo":"7vzm8xcbcp.fsf@assigned-by-dhcp.cox.net","subject":"Re: New way of tracking remote branches -- question","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-06T00:16:57Z","receivedAt":"2007-01-06T00:16:57Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Luben Tuikov writes:\n> \n> > I can see that the remote heads are where they are supposed to be\n> > but no local tracking heads are created (by default). I had\n> > to do this manually.\n> >\n> > Old behavior was that git did that for you automatically.\n> > So I suppose this is another newbie protection.\n> \n> A very fuzzily stated question which is hard to answer, but I do\n> not think it is another newbie protection, if it apparently is\n> actively hurting you. Also the documentation may need to be\n> updated to teach you enough about how to achieve what you want.\n> \n> You can see where remote heads are by doing what? ls-remote?\n> \"Old behaviour\" for what configuration?\n> \n> A fresh clone made with a recent version sets things up to track\n> all remote branches from the repository you cloned from under\n> remotes/origin/, and it even tracks new ones as they are added\n> at the remote, so you probably are doing something different\n> from the default configuration that has:\n> \n> remotes.origin.fetch = +refs/heads/*:refs/remotes/origin/*\n\nThat's exactly what I have, but \"git branch\" shows only \"master\".\nThe other branches are indeed in refs/remotes/origin/ but I want\nthem in refs/heads/ so I had to do that manually by creating\nthe head and add this into .git/config.\n\nOld behavior was more _convenient_.\n\n Luben\n"},{"id":"30943","messageId":"386533.4292.qm@web31809.mail.mud.yahoo.com","threadId":"6238","inReplyTo":"7vmz4xcacr.fsf@assigned-by-dhcp.cox.net","subject":"Re: New way of tracking remote branches -- question","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-06T00:39:21Z","receivedAt":"2007-01-06T00:39:21Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > Luben Tuikov writes:\n> >\n> >> I can see that the remote heads are where they are supposed to be\n> >> but no local tracking heads are created (by default). I had\n> >> to do this manually.\n> >>\n> >> Old behavior was that git did that for you automatically.\n> >> So I suppose this is another newbie protection.\n> >\n> > A very fuzzily stated question which is hard to answer, but I do\n> > not think it is another newbie protection, if it apparently is\n> > actively hurting you. Also the documentation may need to be\n> > updated to teach you enough about how to achieve what you want.\n> \n> Can you state the problem you observed about the recent git in a\n> way that is easier to debug?\n> \n> For example, you could state:\n> \n> \tWith older git (I verified that v1.3.0 still works like\n> \tthis), I used to be able to just say:\n> \n> \t\t$ git fetch\n> \n> \t(this is the exact command line -- I am not giving a URL\n> \tnor even \"origin\" after \"git fetch\"). When the upstream\n> \tcreated a new branch 'blah', the above command created a\n> \tnew local branch 'blah' automatically for me. With the\n> \ttip of 'master' (e27e609), this does not happen anymore.\n> \n> \tMy configuration is that I have .git/remotes/origin file\n> \twhose contents is .... I do not have any remote.*.url,\n> \tremote.*.fetch, nor branch.*.remote configuration variables.\n> \n> to be more helpful.\n> \n> I am not dismissing your message as whining. You probably have\n> hit a regression while we adopted the BCP to encourage separate\n> remote layout, and I would like to understand the issue.\n\nAnd I'm not whining. It just that when I've done something 1000\ntimes and all of a sudden I do the same thing and didn't see the\nexpected behaviour, I posted.\n\n\"git-pull\" didn't \"create\" the branches in the place I was\nexpecting. I.e. while they are in .git/refs/remotes/origin/\nthey are not in .git/refs/heads.\n\nThen I manually created the heads in .git/refs/heads\nand manually added that to .git/config, i.e. the [branch]\npart.\n\nI was hoping I wouldn't need to do that at all, as old\ngit-pull exposed remote branches, or I was expecting to\nat least find a git command to do this 2nd additional\nmanual step for me.\n\n Luben\n"},{"id":"30944","messageId":"7v8xghariv.fsf@assigned-by-dhcp.cox.net","threadId":"6238","inReplyTo":"7vejq9c9tf.fsf@assigned-by-dhcp.cox.net","subject":"Re: New way of tracking remote branches -- question","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-06T01:11:04Z","receivedAt":"2007-01-06T01:11:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Luben Tuikov writes:\n>\n>> I can see that the remote heads are where they are supposed to be\n>> but no local tracking heads are created (by default). I had\n>> to do this manually.\n>\n> Ah, after firing off a few messages, I think I now guessed\n> what you are talking about correctly.\n>\n> You are talking about the separate remote layout \"git clone\"\n> creates, and talking about the fact that there is nothing in\n> refs/heads/ except master while refs/remotes/origin/ mirrors\n> what the remote side has faithfully, aren't you?\n>\n> If that is the case, I can explain. It is a good topic to talk\n> about.\n\nDisclaimer. I am not very good at defending what I do not fully\nagree with, and the separate remote is one of them, but because\nit has become the default layout, let me try.\n\nWhen cloning from a repository with a single branch (like\nLinus's linux-2.6), the traditional layout created\nheads/{origin,master}. Origin is a tracking branch that you\nwere not supposed to build on top of (or reset to move around,\nfor that matter), and master is where you do your work (or you\ndo your work elsewhere and use master to integrate them).\n\nThe separate remote layout creates remotes/origin/{HEAD,master}\nthat you can still refer to with \"origin\" (because sha1_name\nknows about \"refs/remotes/%s/HEAD\") and is a tracking branch.\nIt also creates heads/master which is where you do your work (or\nintegration).\n\nSo from the high level view, the usage has not changed for the\nsimplest case with the new layout.\n\nWhen the other side have more than one branch (say, 'master' and\n'next'), the story is different. The traditional layout created\nheads/next in addition. This _is_ a tracking branch that you\nwere not supposed to build on top of or reset.\n\nThe problem is that \"git branch\" listing does not tell you the\ndifferences between 'master' and 'next' with the traditional\nlayout. They happen to be the same name as what the remote side\nhas, but they are VASTLY different. 'master' is *your* local\nbranch you can freely use to do whatever you want, and does not\nhave to have ANYTHING to do with the remote 'master' ('origin'\nis the mirror of remote 'master', not 'master'). While 'next'\nis the mirror of remote 'next' and you are not even supposed to\ntouch it.\n\nThe separate remote layout instead adds remotes/origin/next. It\ndoes not fork heads/next from it when a clone is made. I guess\nwe could do that, and I do not have a strong preference myself.\nI think other poeple on the list (especially the ones who wanted\nseparate remote layout) prefer not to have the automatic fork of\nall remote branches.\n\nI think the current way reflects the distributed nature of git\nbetter.\n\n * You may not necessarily care what happens on the non-primary\n branch at the remote side. You are not forced to have the\n same branch structure as the remote has. People who happily\n track 'master' can even forget about other branches tracked\n in remotes/origin/ and have heads/master and nothing else in\n the local branch namespace.\n\n * Your heads/ namespace is of your own. The repository clone\n sets up arranges the master branch to start from the same\n commit as where you cloned from, and sets up so that changes\n made on the master at the remote is merged into your master,\n but that is merely a convention that was deemed as the most\n common and the most convenient.\n\nOne inconvenience for disciplined people is that traditional\nlayout allowed \"git checkout next\" to compile and install what\nthe remote side placed on a non-primary branch 'next'.\n\nIf you wanted to do _ANY_ development on top of it (even if that\nwas just to set '#define DEBUG 1'), however, you would need to\nbranch off of it, say \"git checkout -b my-next next\", so the\nabove inconvenience is arguably very minor. On the other hand,\nthe downside are the pollution of your own heads/ namespace\n(having your forked branch and remote tracking branch means\nheads/ would have next and pu from me and my-next and my-pu you\nwork on), and some people are not as careful and disciplined as\nyou are and have made mistakes of committing their own changes\nwhile on such remote tracking branches (you can call the latter\npart \"newbie protection\"). The next 'git fetch', especially\nwhen it was forced _and_ was done while on 'next', was rather\nunpleasant. Of course, discipined people like you and me would\nnever do that, but we are not the only two people in the\nuniverse ;-).\n\nThe issue of \"checking the tracking branch out to look-and-see\"\nis going to be addressed by the upcoming detached HEAD support,\nso personally I do not think it will be a huge problem. You\nwould have to say \"git checkout origin/next\" for it with the new\nlayout.\n\nAnother thing the separate remote gives us is to make it easier\nto interact with more than one remote, by having a new directory\nnext to remotes/origin/ directory. If you used the traditional\nlayout, your heads/ namespace would explode because you would\nhave to have something like:\n\n\theads/origin\t\t-- from linux-2.6's master\n heads/origin-libata\t-- from jgarzik libata ALL\n\theads/origin-sii-lbt\t-- from jgarzik libata sii-lbt\n ...\n\nin a flat namespace intermixed with your own development\nbranches, instead of:\n\n\tremotes/origin/master\t-- from linux-2.6's master\n remotes/libata/ALL\n remotes/libata/sii-lbt\n\t...\n\ngrouped together by where they come from (and they cannot\npossibly be mucked around directly thanks to being in remotes/\nhierarchy), separated from any of your own development branches\nthat are in heads/.\n\nAlso, this is only about the default layout clone makes, and the\nrefs are not packed, so you can easily move remotes/origin/*\n(except 'HEAD') to heads/ immediately after making a clone and\nset up remotes.*.fetch configuration to match the traditional\nlayout if that is what you find more convenient. The operation\nin a repository layed out in the traditional way is still fully\nsupported (and will continue to be -- that's what old timers\nuse), and there is not even a reason to change your work habit\nby converting an existing repository.\n"},{"id":"30953","messageId":"459F056D.8010705@midwinter.com","threadId":"6238","inReplyTo":"7v8xghariv.fsf@assigned-by-dhcp.cox.net","subject":"Re: New way of tracking remote branches -- question","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-06T02:11:57Z","receivedAt":"2007-01-06T02:11:57Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> I think other poeple on the list (especially the ones who wanted\n> separate remote layout) prefer not to have the automatic fork of\n> all remote branches.\n> \n\nI'm a big fan of separate remote, and while I don't necessarily think \nautomatic fork should be the default behavior, it might be nice to have \nan option for it, including setting up the appropriate config entries so \npush/pull do the expected things.\n\nIf that doesn't sound palatable, maybe an option to specify which remote \nbranch to check out by default -- that way you can tell someone to run a \nparticular git-clone command to get a local copy of a specific branch of \nyours. We just had a need for that here today, in fact. The current \nbehavior is pretty screwy when you want to tell someone to clone your \ndevelopment environment to look at what you're doing; they don't have a \ngood way of knowing which of your branches they're going to end up with, \nsince you might be working in any of them when they happen to run \ngit-clone. You end up having to say, \"Run git-clone, then run \ngit-branch, and if you don't see '* xyz', then run 'git-checkout -b xyz \norigin/xyz'.\"\n\n-Steve\n"},{"id":"30972","messageId":"20070106141032.GB28972@thunk.org","threadId":"6238","inReplyTo":"7v8xghariv.fsf@assigned-by-dhcp.cox.net","subject":"Re: New way of tracking remote branches -- question","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-01-06T14:10:32Z","receivedAt":"2007-01-06T14:10:32Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Jan 05, 2007 at 05:11:04PM -0800, Junio C Hamano wrote:\n> * Your heads/ namespace is of your own. The repository clone\n> sets up arranges the master branch to start from the same\n> commit as where you cloned from, and sets up so that changes\n> made on the master at the remote is merged into your master,\n> but that is merely a convention that was deemed as the most\n> common and the most convenient.\n\nThe other nice thing about the new scheme is that if new branches\nappear in the remote repository, they automatically show up in\nremote/origin/*. Before, if new branches showed up after the initial\nclone, you'd never know about it and it wouldn't be possible to\nautomatically create new branches in heads/ since it might conflict\nwith an originally existing branch in the local namespace. So IMHO,\nthe separation of namespace is definitely a good thing.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"31205","messageId":"524590.40333.qm@web31802.mail.mud.yahoo.com","threadId":"6238","inReplyTo":"7v8xghariv.fsf@assigned-by-dhcp.cox.net","subject":"Re: New way of tracking remote branches -- question","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-09T07:45:09Z","receivedAt":"2007-01-09T07:45:09Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"> Junio C Hamano writes:\n> \n> If you wanted to do _ANY_ development on top of it (even if that\n> was just to set '#define DEBUG 1'), however, you would need to\n> branch off of it, say \"git checkout -b my-next next\", so the\n> above inconvenience is arguably very minor. On the other hand,\n> the downside are the pollution of your own heads/ namespace\n> (having your forked branch and remote tracking branch means\n> heads/ would have next and pu from me and my-next and my-pu you\n> work on), and some people are not as careful and disciplined as\n> you are and have made mistakes of committing their own changes\n> while on such remote tracking branches (you can call the latter\n> part \"newbie protection\"). The next 'git fetch', especially\n> when it was forced _and_ was done while on 'next', was rather\n> unpleasant. Of course, discipined people like you and me would\n> never do that, but we are not the only two people in the\n> universe ;-).\n\nLOL, I love your sense of humor here! :-)\n\n> The issue of \"checking the tracking branch out to look-and-see\"\n> is going to be addressed by the upcoming detached HEAD support,\n> so personally I do not think it will be a huge problem. You\n> would have to say \"git checkout origin/next\" for it with the new\n> layout.\n\nI guess, what I want is still to be able to \"see\" remotes/\nwhen I do \"git branch\".\n\nSometimes I don't care to check out the remote branch, I just\nwant to rev-list it. Sometimes I do check it out so I can\ntake a look and when I pull, I do the required reset, but\nas you said above :-) this requires discipline.\n\nAnd of course if I want to do my own development, I branch\noff, as I've done with \"next\", and never forget to \"git-pull . next\"\nafter I pull from you. Again this requires discipline.\n\nBut what I appreciate in git, is this discipline. The fact that\nI'm in control of it and that I have to do it -- keeps my mind sharp.\n\nI really think that the line separating porcelains from git\nshould be drawn at some point.\n\nI think that this \"automatic merge/newbie protection\" policy,\nshould've been well suited to porcelains as opposed to\ngit.\n\n> Another thing the separate remote gives us is to make it easier\n> to interact with more than one remote, by having a new directory\n> next to remotes/origin/ directory. If you used the traditional\n> layout, your heads/ namespace would explode because you would\n> have to have something like:\n> \n> \theads/origin\t\t-- from linux-2.6's master\n> heads/origin-libata\t-- from jgarzik libata ALL\n> \theads/origin-sii-lbt\t-- from jgarzik libata sii-lbt\n> ...\n> \n> in a flat namespace intermixed with your own development\n> branches, instead of:\n> \n> \tremotes/origin/master\t-- from linux-2.6's master\n> remotes/libata/ALL\n> remotes/libata/sii-lbt\n> \t...\n> \n> grouped together by where they come from (and they cannot\n> possibly be mucked around directly thanks to being in remotes/\n> hierarchy), separated from any of your own development branches\n> that are in heads/.\n\nI don't mind this at all, as long as I get to \"see\" it, when\nI do normal git operations, like \"git branch\".\n\nSo maybe we should take it one step at a time and first\nimplement that, still exposing it to \"git branch\" and then\nif porcelains want to establish a policy on top of this,\nthat's fine. But low-level git should not hide this from me.\n\n Luben\n\n> Also, this is only about the default layout clone makes, and the\n> refs are not packed, so you can easily move remotes/origin/*\n> (except 'HEAD') to heads/ immediately after making a clone and\n> set up remotes.*.fetch configuration to match the traditional\n> layout if that is what you find more convenient. The operation\n\nI do find that more convenient, but wouldn't like to have\nto do that, nor to have a script that does it for me to have\nto do it after I clone.\n\nIt would be most convenient when this per-repo layout is\nimplemented, yet I get to see this when I do \"git-branch\".\n\nI guess, most convenent, yet \"newbie-protection\" would be\nto disallow any commits to remotes/* in this way... I'd opt\nfor that wholeheartedly.\n\n Luben\n"},{"id":"31211","messageId":"7vejq4r4ci.fsf@assigned-by-dhcp.cox.net","threadId":"6238","inReplyTo":"524590.40333.qm@web31802.mail.mud.yahoo.com","subject":"Re: New way of tracking remote branches -- question","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-09T08:28:45Z","receivedAt":"2007-01-09T08:28:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> I guess, what I want is still to be able to \"see\" remotes/\n> when I do \"git branch\".\n\nThen do not use \"remotes/\" but hang everything underneath\n\"heads/\" (or \"git branch -a\").\n\nOf course, the next complaint from you would be that the latest\ngit-clone would not make the traditional layout, but ...\n\n> I think that this \"automatic merge/newbie protection\" policy,\n> should've been well suited to porcelains as opposed to\n> git.\n\n... at that point, honestly speaking, I feel that you should do\nyour own \"spartan porcelain\" that lays things out in a way you\nprefer.\n\n> So maybe we should take it one step at a time and first\n> implement that, still exposing it to \"git branch\" and then\n> if porcelains want to establish a policy on top of this,\n> that's fine. But low-level git should not hide this from me.\n\nNo low-level is hiding anything from you.\n\nIt used to be 'find .git/refs/ -type f' was the lowest level,\nand these days git-for-each-ref is the lowest level. \"git\nbranch\" has always been Porcelain.\n\n> I really think that the line separating porcelains from git\n> should be drawn at some point.\n\nAnd drawing this line was done long time ago (notice different\nsections in Documentation/git.txt).\n\nWhile I've been claiming that I do not do Porcelain, the nature\nof what are shipped with git have changed enough over time. The\nPorcelain-ish has long been \"barely usable spartan set\", hoping\nthat people would do different porcelains depending on their\nneeds, but that has never materialized, except perhaps a notable\nexample of StGIT.\n\nI described my position on recent focus on Porcelain-ish in the\ninitial \"digression\" part of this:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/34908/focus=34914\n\nWe've taken \"one step at a time\" by first introducing separate\nremote layout as an option, taught 'git branch' the needed\noptions such as -a and -r, and then made this the default\nlayout. It still looks _different_ to me from what I am used\nto, but that's just traditionalist speaking and I cannot really\ndeny the advantage of the separate remote layout offers. In\nother words, we have been doing \"one step at a time\".\n"},{"id":"31212","messageId":"181306.34035.qm@web31814.mail.mud.yahoo.com","threadId":"6238","inReplyTo":"7vejq4r4ci.fsf@assigned-by-dhcp.cox.net","subject":"Re: New way of tracking remote branches -- question","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-09T08:41:30Z","receivedAt":"2007-01-09T08:41:30Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> > I guess, what I want is still to be able to \"see\" remotes/\n> > when I do \"git branch\".\n> \n> Then do not use \"remotes/\" but hang everything underneath\n> \"heads/\" (or \"git branch -a\").\n> \n> Of course, the next complaint from you would be that the latest\n> git-clone would not make the traditional layout, but ...\n\nWhat I meant was something of the lines of \"git branch -r\".\nAs I said, I don't mind the new way of seprating remote\nbranches per repo as is done by remotes/*/ .\n\n> We've taken \"one step at a time\" by first introducing separate\n> remote layout as an option, taught 'git branch' the needed\n> options such as -a and -r, and then made this the default\n> layout. It still looks _different_ to me from what I am used\n> to, but that's just traditionalist speaking and I cannot really\n> deny the advantage of the separate remote layout offers. In\n> other words, we have been doing \"one step at a time\".\n\nMe neither. I also think there is an advantage of separately\ntracking remotes as per remotes/*/ , so that organization is\nbetter, i.e. per remote repo.\n\n Luben\n"},{"id":"31214","messageId":"46a038f90701090057w31d46530x4f70a76287bbef33@mail.gmail.com","threadId":"6238","inReplyTo":"7vejq9c9tf.fsf@assigned-by-dhcp.cox.net","subject":"Re: New way of tracking remote branches -- question","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-01-09T08:57:09Z","receivedAt":"2007-01-09T08:57:09Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/6/07, Junio C Hamano wrote:\n> You are talking about the separate remote layout \"git clone\"\n> creates, and talking about the fact that there is nothing in\n> refs/heads/ except master while refs/remotes/origin/ mirrors\n> what the remote side has faithfully, aren't you?\n>\n> If that is the case, I can explain. It is a good topic to talk\n> about.\n\nIt's confusing me too ;-) though I think I'm getting to understand it.\nStill more comfortable with the cogito style, personally. The only\nthing I see as a clear improvement in git \"remotes\" is that I can\nfetch a bundle of heads for review. And that it can track heads that\nrewind. All the magic that happens if you have multiple pull lines is\na bit scary, the kind of thing that should be disallowed or use a\ndifferent syntax.\n\nOne aspect that I am getting used to, but I still consider slightly\nbogus is that as we have added a layer of indirection, what used to\npoint to a specific remote branch now points to a bundle or remotes\nheads.\n\nIt is quite disconcerting to say git-pull origin, and see that pu is\nbeing pulled in. And fortunately I'm tracking repos that don't have\nan 'origin' head. Otherwise I'd get origin/origin. :-(\n\n[reading on now...]\n\n\n\nmartin\n"}]}