{"thread":{"id":"43120","subject":"Re: [RFD] making separate-remote layout easier to use","startedAt":"2006-11-25T21:53:07Z","lastAt":"2006-11-30T21:22:15Z","messageCount":22,"participants":["Jakub Narebski","Junio C Hamano","Shawn Pearce","Jon Loeliger","Josef Weidendorfer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"297811","messageId":"7v1wnr19do.fsf@assigned-by-dhcp.cox.net","threadId":"43120","inReplyTo":null,"subject":"[RFD] making separate-remote layout easier to use","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-25T21:53:07Z","receivedAt":"2006-11-25T21:53:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Now separate-remote layout is the default for newly cloned\nrepositories, I think it is a good time to make further effort\nto make things easier to use. Here are some of the ideas off\nthe top of my head.\n\n* Do not change what branch the sole local branch is named.\n\nIn the current implementation, we find out what branch the\nremote HEAD points at, and match the name of the sole local\nbranch to it. HEAD of most central distribution point\nrepositories that use git with the default configuration have\nHEAD pointing at refs/heads/master and a cloned repository would\ncontinue to use refs/heads/master as the sole local branch when\nit starts as before, but some projects may use alternate\nwordings such as 'main', and a new repository would have\nrefs/heads/main branch when cloned from such a repository\ninstead. I think this behaviour is a reasonable default, so\nlet's keep this.\n\nDistribution point repositories are of interest here, because\nthat is what most people clone from, and this message is about\nmaking the default easier to use by those casual cloners.\n\n* Change the default contents of $GIT_DIR/remotes/origin\n\nCurrently we list all the remote branches that exist when the\nclone is made, making sure that the branch pointed at by HEAD at\nthe remote is listed first. The intent is to track every branch\nat the remote but merge in the \"primary\" branch to us.\n\nTwo issues that have been raised about this is:\n\n - the intent to track every branch is good, but the current\n implementation means we would not notice new branches at the\n remote.\n\n - merging the \"primary\" branch is good only when the user is on\n the corresponding \"primary\" branch. It is usually a wrong\n thing to do when on another branch.\n\nThe first issue can be solved, with the help of recent \"glob\npattern refspec in fetch\" from Andy. I am thinking about making\nthe default contents of $GIT_DIR/remotes/origin to be:\n\n\tURL: \n\tPull: +refs/heads/:refs/remotes//\n\tPull: +refs/heads/*:refs/remotes//*\n\nto address this issue.\n\n\tSide note: is what HEAD pointed at at the\n remote when the clone was made, and is usually\n 'origin' but \"git clone -o $origin\" can override it.\n\nForcing with '+' is debatable, but with separate-remote layout,\nremotes/*/ hierarchy is to track what the remote has, and you\ncannot do much else other than noticing and warning when the\nremote end does funny things to its refs anyway, so I think\nhaving '+' might be a better default.\n\nThe right thing to do to address the second issue is less clear.\nIf the \"upstream\" has two more-or-less equally prominent\nbranches, say 'main' and 'test', it may make sense to use\ncorresponding two branches on the local side and merge 'main'\nfrom the remote when on local 'main' and merge 'test' when on\nlocal 'test'. Even when dealing with a specific topic branch,\nthat would hold true for most of the time. A topic branch\nrefs/heads/bug#2073 to work on the bug 2073 can be published at\nthe central distribution point. The proposed updates to\n$GIT_DIR/remotes/origin file would track it with\nrefs/remotes/origin/bug#2073 and interested people can create a\nlocal branch refs/heads/bug#2073 from it and work on it, which\nmakes it easy to polish a topic branch in a collaborative way.\n\nI am not sure if 'merge in corresponding branch' is the only\nvalid workflow, however. I am reluctant to make the system\nautomatically do so if the solution makes other workflows more\npainful to follow. Automatically merging remotes/origin/$foo\nwhen on $foo branch is not good enough, in other words (also,\nthere may be a hierarchy under remotes/ other than origin). It\nmight make sense to introduce \"Merge: \" in remotes/ file and if\nthey are present use \"Pull: \" only to decide what are fetched\nand use \"Merge: \" to decide what is merged (if we were doing the\nsystem from scratch, the former would have been named \"Fetch: \"\nbut it is too late now).\n"},{"id":"296561","messageId":"ekafpm$fs7$1@sea.gmane.org","threadId":"43120","inReplyTo":"7v1wnr19do.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-25T22:25:35Z","receivedAt":"2006-11-25T22:25:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Now separate-remote layout is the default for newly cloned\n> repositories, I think it is a good time to make further effort\n> to make things easier to use. Here are some of the ideas off\n> the top of my head.\n[...]\n> * Change the default contents of $GIT_DIR/remotes/origin\n\nThe question is: do we continue to use remotes/ file, or do we\nsave remotes info in the config file: remote..url,\nremote..fetch, remote..push and branch..merge\n(in our case '[remote \"origin\"]' section)?\n \n> Currently we list all the remote branches that exist when the\n> clone is made, making sure that the branch pointed at by HEAD at\n> the remote is listed first. The intent is to track every branch\n> at the remote but merge in the \"primary\" branch to us.\n> \n> Two issues that have been raised about this is:\n> \n> - the intent to track every branch is good, but the current\n> implementation means we would not notice new branches at the\n> remote.\n> \n> - merging the \"primary\" branch is good only when the user is on\n> the corresponding \"primary\" branch. It is usually a wrong\n> thing to do when on another branch.\n> \n> The first issue can be solved, with the help of recent \"glob\n> pattern refspec in fetch\" from Andy. I am thinking about making\n> the default contents of $GIT_DIR/remotes/origin to be:\n> \n> URL: \n> Pull: +refs/heads/:refs/remotes//\n> Pull: +refs/heads/*:refs/remotes//*\n> \n> to address this issue.\n\nI hope that it also works with the remote.origin config file\nsection instead of $GIT_DIR/remotes/origin\n\n> Side note: is what HEAD pointed at at the\n> remote when the clone was made, and is usually\n> 'origin' but \"git clone -o $origin\" can override it.\n> \n> Forcing with '+' is debatable, but with separate-remote layout,\n> remotes/*/ hierarchy is to track what the remote has, and you\n> cannot do much else other than noticing and warning when the\n> remote end does funny things to its refs anyway, so I think\n> having '+' might be a better default.\n\nPerhaps, perhaps not. It would be nice to have configuration option\nthat would tell that history of given branch is being changed, and\nthe ability to ask about it remotely, so git-clone would be able\nto add this + _when needed_ automatically.\n\nBut it's a fact that with separate remote the need to use fast-forward\ncheck is lessened, and it might be more important to not confuse first\ntime user with having to modify $GIT_DIR/remotes/origin or remote.origin\nconfig section to fetch from the repository he/she cloned from.\n\n> The right thing to do to address the second issue is less clear.\n> If the \"upstream\" has two more-or-less equally prominent\n> branches, say 'main' and 'test', it may make sense to use\n> corresponding two branches on the local side and merge 'main'\n> from the remote when on local 'main' and merge 'test' when on\n> local 'test'. Even when dealing with a specific topic branch,\n> that would hold true for most of the time. A topic branch\n> refs/heads/bug#2073 to work on the bug 2073 can be published at\n> the central distribution point. The proposed updates to\n> $GIT_DIR/remotes/origin file would track it with\n> refs/remotes/origin/bug#2073 and interested people can create a\n> local branch refs/heads/bug#2073 from it and work on it, which\n> makes it easy to polish a topic branch in a collaborative way.\n> \n> I am not sure if 'merge in corresponding branch' is the only\n> valid workflow, however. I am reluctant to make the system\n> automatically do so if the solution makes other workflows more\n> painful to follow. Automatically merging remotes/origin/$foo\n> when on $foo branch is not good enough, in other words (also,\n> there may be a hierarchy under remotes/ other than origin). It\n> might make sense to introduce \"Merge: \" in remotes/ file and if\n> they are present use \"Pull: \" only to decide what are fetched\n> and use \"Merge: \" to decide what is merged (if we were doing the\n> system from scratch, the former would have been named \"Fetch: \"\n> but it is too late now).\n\nIf you add \"Merge: \" in remotes/, then please add it also in\nremote section in config file. Config file has now \nbranch..merge (and it would be nice if clone would\nset ou this for local branches corresponding to remote branches),\nbut it is not the same.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294082","messageId":"7vvel3yuzz.fsf@assigned-by-dhcp.cox.net","threadId":"43120","inReplyTo":"ekafpm$fs7$1@sea.gmane.org","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-25T23:19:44Z","receivedAt":"2006-11-25T23:19:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n>\n>> Now separate-remote layout is the default for newly cloned\n>> repositories, I think it is a good time to make further effort\n>> to make things easier to use. Here are some of the ideas off\n>> the top of my head.\n> [...]\n>> * Change the default contents of $GIT_DIR/remotes/origin\n>\n> The question is: do we continue to use remotes/ file, or do we\n> save remotes info in the config file: remote..url,\n> remote..fetch, remote..push and branch..merge\n> (in our case '[remote \"origin\"]' section)?\n\nIt is not \"the question\"; it is irrelevant because\n$GIT_DIR/remotes/origin and [remote \"origin\"] are pretty much\ninterchangeable, and will hopefully continue to be.\n\n [remote \"origin\"]\n url = master.kernel.org:/pub/scm/git/git.git/\n fetch = +refs/heads/master:refs/remotes/origin/master\n fetch = +refs/heads/*:refs/remotes/origin/*\n\nwould be the way to express the equilvalent of the example in\nthe previous message.\n\n\n\n"},{"id":"297189","messageId":"200611260034.23974.jnareb@gmail.com","threadId":"43120","inReplyTo":"7vvel3yuzz.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-25T23:34:23Z","receivedAt":"2006-11-25T23:34:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski writes:\n> \n>> Junio C Hamano wrote:\n>>\n>>> Now separate-remote layout is the default for newly cloned\n>>> repositories, I think it is a good time to make further effort\n>>> to make things easier to use. Here are some of the ideas off\n>>> the top of my head.\n>> [...]\n>>> * Change the default contents of $GIT_DIR/remotes/origin\n>>\n>> The question is: do we continue to use remotes/ file, or do we\n>> save remotes info in the config file: remote..url,\n>> remote..fetch, remote..push and branch..merge\n>> (in our case '[remote \"origin\"]' section)?\n> \n> It is not \"the question\"; it is irrelevant because\n> $GIT_DIR/remotes/origin and [remote \"origin\"] are pretty much\n> interchangeable, and will hopefully continue to be.\n> \n> [remote \"origin\"]\n> url = master.kernel.org:/pub/scm/git/git.git/\n> fetch = +refs/heads/master:refs/remotes/origin/master\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> \n> would be the way to express the equilvalent of the example in\n> the previous message.\n\nWell, the question is if git-clone would generate appropriate config \nentries in addition to or instead of $GIT_DIR/remotes/origin file...\n\nBy the way, what do you think about extended refspec syntax, namely\nin addition to : it would allow to say\n::?\n-- \nJakub Narebski\n"},{"id":"295733","messageId":"20061126031421.GC29394@spearce.org","threadId":"43120","inReplyTo":"7vvel3yuzz.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-26T03:14:21Z","receivedAt":"2006-11-26T03:14:21Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski writes:\n> > The question is: do we continue to use remotes/ file, or do we\n> > save remotes info in the config file: remote..url,\n> > remote..fetch, remote..push and branch..merge\n> > (in our case '[remote \"origin\"]' section)?\n> \n> It is not \"the question\"; it is irrelevant because\n> $GIT_DIR/remotes/origin and [remote \"origin\"] are pretty much\n> interchangeable, and will hopefully continue to be.\n\nI'm all for:\n\n * changing the default made git-clone to be [remote \"\"]\n * continuing to support parsing of $GIT_DIR/remotes/*\n\nWe moved away from the $GIT_DIR/branches directory to\n$GIT_DIR/remotes, yet we still support $GIT_DIR/branches in\nremote handling code. I see no reason why we cannot start to use\nremote..url by default while continuing to support the older\nbranches and remotes formats.\n\nFor one thing the newer remote..fetch seems to make more sense\nto new users than Pull: lines do. For another it appears to be\nsupported since v1.4.0, which was released June 10th. Most users\ncloning a repository with >1.4.4.1 will probably only use 1.4.0\nor later on that same repository, so there is probably low risk of\nbreakage due to the remote not being recognized by a pre-1.4.0 Git.\n\n-- \n"},{"id":"296434","messageId":"20061126033433.GD29394@spearce.org","threadId":"43120","inReplyTo":"ekafpm$fs7$1@sea.gmane.org","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-26T03:34:33Z","receivedAt":"2006-11-26T03:34:33Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> Junio C Hamano wrote:\n> > Pull: +refs/heads/*:refs/remotes//*\n> \n> I hope that it also works with the remote.origin config file\n> section instead of $GIT_DIR/remotes/origin\n\nYes, it does. Fortunately Git is relatively consistent. :-)\n \n> > Forcing with '+' is debatable, but with separate-remote layout,\n> > remotes/*/ hierarchy is to track what the remote has, and you\n> > cannot do much else other than noticing and warning when the\n> > remote end does funny things to its refs anyway, so I think\n> > having '+' might be a better default.\n> \n> Perhaps, perhaps not. It would be nice to have configuration option\n> that would tell that history of given branch is being changed, and\n> the ability to ask about it remotely, so git-clone would be able\n> to add this + _when needed_ automatically.\n> \n> But it's a fact that with separate remote the need to use fast-forward\n> check is lessened, and it might be more important to not confuse first\n> time user with having to modify $GIT_DIR/remotes/origin or remote.origin\n> config section to fetch from the repository he/she cloned from.\n\nYes. From an out-of-the-box-make-Git-appear-to-be-easier-to-use\npoint of view tossing + into the Pull:/remote..fetch setup\nmight seem like the right thing to do. It lets the end-user blindly\nfollow the upstream repository they cloned from. Almost.\n\nThe problem becomes when the user makes a topic branch off say\nJunio's `pu` branch and later after doing a fetch and looking at\nthe log of `remotes/origin/pu` decide to pull the updated `pu`\ninto their topic branch, so they can continue testing. But now\nthey are in merge hell as Junio has completely rebased `pu` and\nwhat was there isn't, and what's there now ain't compatible...\nand the new user curses at Git.\n\nNeeding to put + in front of a refspec (or needing to fetch it with\n--force) is the user agreeing that something _evil_ is going on with\nthe upstream and that they acknowledge this may cause problems for\nthem locally.\n\nI would prefer to see the upstream be able to publish a short\ndescription of each branch, where the repository owner can describe\nthe policy of that branch, as well as have a machine readable\nsetting on each branch indicating if that branch will be rewound\nfrom time to time, or never rewound.\n\ngit-clone should skip rewinding branches by default, unless the user\nadds an option (e.g. --include-rewinding-branches). This way new\nusers to git.git don't get the `pu` branch unless they really mean\nto get it, at which point they have hopefully also read the upstream's\ndescription of the `pu` branch and its rewinding policy, and can\nat least start to grasp what is going to happen if they start to\nwork with the branch.\n \n> > I am not sure if 'merge in corresponding branch' is the only\n> > valid workflow, however. I am reluctant to make the system\n> > automatically do so if the solution makes other workflows more\n> > painful to follow. Automatically merging remotes/origin/$foo\n> > when on $foo branch is not good enough, in other words (also,\n> > there may be a hierarchy under remotes/ other than origin). It\n> > might make sense to introduce \"Merge: \" in remotes/ file and if\n> > they are present use \"Pull: \" only to decide what are fetched\n> > and use \"Merge: \" to decide what is merged (if we were doing the\n> > system from scratch, the former would have been named \"Fetch: \"\n> > but it is too late now).\n> \n> If you add \"Merge: \" in remotes/, then please add it also in\n> remote section in config file. Config file has now \n> branch..merge (and it would be nice if clone would\n> set ou this for local branches corresponding to remote branches),\n> but it is not the same.\n\nI'm against adding anything to the remotes/ file format.\n\nWe already have branch..merge to indicate what the default\nsource for a git-pull on the branch named should be.\ngit-branch probably should fill that entry in when a branch is\ncreated from a remotes ref.\n\n-- \n"},{"id":"298120","messageId":"7virh2zxni.fsf@assigned-by-dhcp.cox.net","threadId":"43120","inReplyTo":"200611260034.23974.jnareb@gmail.com","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-26T03:37:05Z","receivedAt":"2006-11-26T03:37:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Well, the question is if git-clone would generate appropriate config \n> entries in addition to or instead of $GIT_DIR/remotes/origin file...\n\nWhat I meant by \"irrelevant\" is that it is purely syntax. I\nwould rather nail down the desired semantics first, and then\nworry about the syntax. We have done remotes/origin file by\ndefault and allowed the same thing specified in configuration\nfile for people who prefer configuration file, and I do not see\nan immediate need to change that.\n\nOnly if/when the desired semantics turns out to be too complex\nto be expressed in the remotes/ file scheme and at the same time\nif configuration file is easier to express the same information,\nwe should start talking about favoring configuration file over\nremotes/ file, and perhaps generating the config entries by\ndefault without generating remotes/.\n\nIn either case, I do not think generating _both_ by default is a\nbad idea. They will become out of sync and the user either need\nto delete one or the other to avoid confusion.\n\n> By the way, what do you think about extended refspec syntax, namely\n> in addition to : it would allow to say\n> ::?\n\nI do not think it is reasonable to assume that one remote branch\nis to be always merged into one fixed local branch, so that is\ntoo limiting as an extension. In the configuration file, I\nthink we already allow the default remote to be fetched from and\nremote branches to be merged per branch statically. A\nreasonable thing to do is to see how satisfied users are with\nthat facility, what they find missing there. Worrying about the\nsyntax should wait until we know what kind of things need to be\nexpressed; that can be done both by extending the existing\nconfiguration and/or introducing a new entries in remotes/\nfiles but the point is that is mere implementation detail.\n\n\n"},{"id":"295914","messageId":"7v4psmzx4w.fsf@assigned-by-dhcp.cox.net","threadId":"43120","inReplyTo":"20061126031421.GC29394@spearce.org","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-26T03:48:15Z","receivedAt":"2006-11-26T03:48:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> We moved away from the $GIT_DIR/branches directory to\n> $GIT_DIR/remotes, yet we still support $GIT_DIR/branches in\n> remote handling code.\n\nIIRC, git never used \"branches\", so there was no \"moving away\".\nIt was merely to interpret what cg-init left in the repository.\nSince the very early days remotes/ has been _the_ format git\nused, and I do not see any strong reason to change it now. The\ncontinued support for branches is an irrelevant topic and is not\na justification to favor configuration over remotes/ nor the\nother way around.\n\n> For one thing the newer remote..fetch seems to make more sense\n> to new users than Pull: lines do.\n\nThat is quite subjective.\n\n> ..., so there is probably low risk of\n> breakage ...\n\nAgain, \"low risk of breakage\" does not justify switching.\n\nAs I said in the other message, I think configuration vs remotes/\nis futile subject and premature topic to talk about before\nnailing down what semantics we would want. Either format can\nhave the expressive power, once we know what we want to express.\n\n"},{"id":"297736","messageId":"7vvel2yi2u.fsf@assigned-by-dhcp.cox.net","threadId":"43120","inReplyTo":"20061126033433.GD29394@spearce.org","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-26T03:58:49Z","receivedAt":"2006-11-26T03:58:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Needing to put + in front of a refspec (or needing to fetch it with\n> --force) is the user agreeing that something _evil_ is going on with\n> the upstream and that they acknowledge this may cause problems for\n> them locally.\n>\n> I would prefer to see the upstream be able to publish a short\n> description of each branch, where the repository owner can describe\n> the policy of that branch, as well as have a machine readable\n> setting on each branch indicating if that branch will be rewound\n> from time to time, or never rewound.\n>\n> git-clone should skip rewinding branches by default, unless the user\n> adds an option (e.g. --include-rewinding-branches). This way new\n> users to git.git don't get the `pu` branch unless they really mean\n> to get it, at which point they have hopefully also read the upstream's\n> description of the `pu` branch and its rewinding policy, and can\n> at least start to grasp what is going to happen if they start to\n> work with the branch.\n\nI like this approach very much.\n\n\n\n"},{"id":"297006","messageId":"20061126042311.GB30001@spearce.org","threadId":"43120","inReplyTo":"7vvel2yi2u.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-26T04:23:11Z","receivedAt":"2006-11-26T04:23:11Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Shawn Pearce writes:\n> \n> > Needing to put + in front of a refspec (or needing to fetch it with\n> > --force) is the user agreeing that something _evil_ is going on with\n> > the upstream and that they acknowledge this may cause problems for\n> > them locally.\n> >\n> > I would prefer to see the upstream be able to publish a short\n> > description of each branch, where the repository owner can describe\n> > the policy of that branch, as well as have a machine readable\n> > setting on each branch indicating if that branch will be rewound\n> > from time to time, or never rewound.\n> >\n> > git-clone should skip rewinding branches by default, unless the user\n> > adds an option (e.g. --include-rewinding-branches). This way new\n> > users to git.git don't get the `pu` branch unless they really mean\n> > to get it, at which point they have hopefully also read the upstream's\n> > description of the `pu` branch and its rewinding policy, and can\n> > at least start to grasp what is going to happen if they start to\n> > work with the branch.\n> \n> I like this approach very much.\n\nI think the idea of glob'ing off the remote during clone (and\nusing the glob for future fetches) is a good idea. So I think what\nI'm suggesting above is to make glob'ing by default not copy the\nrewinding branches, unless the glob spec itself starts with '+'\n(which is what say --include-rewriting-branches would do).\n\nSo now we're at a point of:\n\n * how do we get this branch information from the remote?\n * how does the remote store this branch information?\n\nI'm leaning towards the repo config for the latter, with say:\n\n\t[branch \"pu\"]\n\t\trewinds = true\n\t\tdescription = This branch contains some proposed updates to git.\\n\\\n\tIt rewinds often, as different updates are proposed or merged into 'next'.\n\nbut looking at that think its rather horrible looking. :-)\n\nHowever for the former it may be useful if the client can download\nthe repo config from the remote repository, such as to fetch\nthe branch description data.\n\n-- \n"},{"id":"297448","messageId":"7vk61iyeq4.fsf@assigned-by-dhcp.cox.net","threadId":"43120","inReplyTo":"20061126042311.GB30001@spearce.org","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-26T05:11:15Z","receivedAt":"2006-11-26T05:11:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> So now we're at a point of:\n>\n> * how do we get this branch information from the remote?\n> * how does the remote store this branch information?\n>\n> I'm leaning towards the repo config for the latter, with say:\n>\n> \t[branch \"pu\"]\n> \t\trewinds = true\n> \t\tdescription = This branch contains some proposed updates to git.\\n\\\n> \tIt rewinds often, as different updates are proposed or merged into 'next'.\n>\n> but looking at that think its rather horrible looking. :-)\n>\n> However for the former it may be useful if the client can download\n> the repo config from the remote repository, such as to fetch\n> the branch description data.\n\nFor the former, I was hoping that we could do a new action\nagainst remote repository that is \"get remote information\". Just\nlike we have \"ls-remote\" as a protocol neutral front-end to get\nwhat git native protocol would give \"peek-remote\", git native\nprotocol would have get-repository-info action to transfer this\ninformation, and http and dumb transports do a file download\nfrom a known file, just like they download files prepared with\nupdate-server-info. Most likely, that get-repository-info is\njust a glorified single file transfer and nothing more.\n\nAs an implementation detail, I think it is one possibility to\nstore this information in the config of the repository being\ncloned from. We should be able to use repo-config to\nparse that file in config-like syntax to extract what we would\nwant, so we do not have to come up with a new syntax nor a new\nparser, which is a big plus.\n\n\tSide note: repo-config, especially the updating side of\n\tit, is one of the programs I find the most brittle in\n\tthe whole system, and it always makes me hesitate when\n\tsomebody proposes to use config file in any important\n\tway read-write for this reason. But this \"reading out\n\tper-branch information from the file\" is read-only so I\n\twould not worry too much about it.\n\nStrictly speaking, however, the config file is a wrong place to\nstore it. For one thing it has core.sharedrepository and\nreceive.denynonfastforwards that are true configuration to\ncontrol the behaviour of git _at_ _the_ _repository_ the\nconfiguration is at. The new \"branch property\" are primarily to\nhelp the other end, and the \"filtering rewinding ones\" we want\nat the clone/fetch side wants that information only and not\ninterested in the true configuration information at that\nrepository.\n\nSo my preference is:\n\n * store it in a fixed filename under $GIT_DIR/$something, in a\n format that is similar to the true config file.\n\n * Dumb transports would just do a file transfer, and we add a\n new command (like \"upload-pack\", \"upload-archive\") for git\n native transport to read that file. We might want to have a\n protocol neutral wrapper (just like \"ls-remote\").\n\n * Cloners and fetchers would do the file transfer and use\n repo-config to read from that transferred file to find out\n which are rewinding branches.\n\n\n\n\n"},{"id":"297255","messageId":"7vfyc6ydus.fsf@assigned-by-dhcp.cox.net","threadId":"43120","inReplyTo":"7virh2zxni.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-26T05:30:03Z","receivedAt":"2006-11-26T05:30:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> In either case, I do not think generating _both_ by default is a\n> bad idea. They will become out of sync and the user either need\n\nEh, excuse me. \"generating both is a BAD idea\" is what I meant...\n"},{"id":"295349","messageId":"20061126073942.GA30518@spearce.org","threadId":"43120","inReplyTo":"7vk61iyeq4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-26T07:39:42Z","receivedAt":"2006-11-26T07:39:42Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Shawn Pearce writes:\n> > So now we're at a point of:\n> >\n> > * how do we get this branch information from the remote?\n> > * how does the remote store this branch information?\n> \n> For the former, I was hoping that we could do a new action\n> against remote repository that is \"get remote information\".\n\nYes, that is completely sane. :)\n \n> As an implementation detail, I think it is one possibility to\n> store this information in the config of the repository being\n> cloned from. We should be able to use repo-config to\n> parse that file in config-like syntax to extract what we would\n> want, so we do not have to come up with a new syntax nor a new\n> parser, which is a big plus.\n\nAlso quite sane. Nobody wants to write new code if we don't really\nhave to. :)\n\n> \tSide note: repo-config, especially the updating side of\n> \tit, is one of the programs I find the most brittle in\n> \tthe whole system, and it always makes me hesitate when\n> \tsomebody proposes to use config file in any important\n> \tway read-write for this reason. But this \"reading out\n> \tper-branch information from the file\" is read-only so I\n> \twould not worry too much about it.\n\nNow you tell me. git-gui uses repo-config for all of its option\ndata. It writes back to the config file to save user configured\noptions, including window layout at quit. It also uses both the\nuser global and the local repository config files. :)\n\nWe can safely update the index, symrefs and refs. Why can't we\nalso safely update the config file? The biggest problem is its\nalso a hand-modified file complete with support for comments,\nso users expect the file to stay intact during edits. Aside from\nthat little issue its really a fairly simple format...\n\n> Strictly speaking, however, the config file is a wrong place to\n> store it. For one thing it has core.sharedrepository and\n> receive.denynonfastforwards that are true configuration to\n> control the behaviour of git _at_ _the_ _repository_ the\n> configuration is at. The new \"branch property\" are primarily to\n> help the other end, and the \"filtering rewinding ones\" we want\n> at the clone/fetch side wants that information only and not\n> interested in the true configuration information at that\n> repository.\n\nYes, of course. I never suggested copy the entire configuration\nas is. What we really want to do is take the branch data from the\nremote and rewrite it for every branch we fetched into a ref, e.g.:\n\n remote:\n [branch \"master\"]\n rewinds = false\n description = blah blah\n\n local:\n [branch \"remotes/origin/master\"]\n rewinds = false\n description = blah blah\n\nwhile skipping other configuration sections and options that have\nno meaning for the local repository. core.sharedrepository is just\none of *many* configuration options that the local repository should\nnot inherit. remote..url is another... etc.\n\n> So my preference is:\n> \n> * store it in a fixed filename under $GIT_DIR/$something, in a\n> format that is similar to the true config file.\n\nAt which point you might as well put it into $GIT_DIR/config.\nPeople are going to use git-repo-config to edit that file, even if\nyou say its brittle and maybe shouldn't be used for heavy editing.\nIts just damn handy.\n \nBesides of which, lets not forget that something like:\n\n [branch \"master\"]\n rewinds = false\n [branch \"pu\"]\n rewinds = true\n\nis not only data for the client to examine. It can be useful in\nsay git-receive-pack as a much more fine-grained alternative to\nreceive.denynonfastforwards. If the server's policy is to not\nrewind a branch then receive-pack shouldn't let a remote user\nrewind it. At which point its useful to have that branch data\nin $GIT_DIR/config. :-)\n\n-- \n"},{"id":"297961","messageId":"7v1wnqwoxz.fsf@assigned-by-dhcp.cox.net","threadId":"43120","inReplyTo":"20061126073942.GA30518@spearce.org","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-26T09:13:28Z","receivedAt":"2006-11-26T09:13:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n>> Strictly speaking, however, the config file is a wrong place to\n>> store it. For one thing it has core.sharedrepository and\n>> receive.denynonfastforwards that are true configuration to\n>> control the behaviour of git _at_ _the_ _repository_ the\n>> configuration is at. The new \"branch property\" are primarily to\n>> help the other end, and the \"filtering rewinding ones\" we want\n>> at the clone/fetch side wants that information only and not\n>> interested in the true configuration information at that\n>> repository.\n>\n> Yes, of course. I never suggested copy the entire configuration\n> as is.\n\nI never misunderstood your plan as such. I was more worried\nabout a case where you clone from a not-so-public repository and\nthe config file has some information of sensitive nature.\nCurrently we do not have any such variable, so I am probably\nbeing a bit paranoid here, but using the config for the purpose\nof what we are discussing right now closes the door to store\nsensitive information and declare that the config file at the\nremote is \"none of the cloner's business\".\n\nHowever,...\n\n> Besides of which, lets not forget that something like:\n>\n> [branch \"master\"]\n> rewinds = false\n> [branch \"pu\"]\n> rewinds = true\n>\n> is not only data for the client to examine. It can be useful in\n> say git-receive-pack as a much more fine-grained alternative to\n> receive.denynonfastforwards. If the server's policy is to not\n> rewind a branch then receive-pack shouldn't let a remote user\n> rewind it. At which point its useful to have that branch data\n> in $GIT_DIR/config. :-)\n\nThis is a good point. If we want to ever have a 'not to be\nleaked' configuration per repository, we can have a separate,\nprivate, configuration file to store that, so I probably should\nnot worry too much about this at this point. I'm Ok with having\nthis in the usual config -- the convenience outweighs the\npurity.\n\nTo summarize:\n\n * A repository can have branch.\"foo\".rewinds configuration to\n mark the \"foo\" branch to be subject to rewinding. This\n configuration variable defaults to false.\n\n * Receive.denynonfastforwards is currently a boolean but a new\n value, \"per-branch\", is also allowed. When it is set to\n \"per-branch\", non fast-forward update is allowed only when\n branch.\"foo\".rewinds is true for the branch.\n\n * A cloner creates \"Pull: refs/heads/*:refs/remotes/origin/*\"\n (or config equivalent) upon cloning. When it clones, it\n downloads the config from the remote in order to see which\n are marked as \"rewinds\". It makes tracking branches for only\n the ones that are not marked as \"rewinds\" by default. We\n might have an option to do '+' variant glob, and clone all\n branches.\n\n * Subsequent fetch, when the glob is not '+' variant, would\n download the config from the remote in order to see which are\n marked as \"rewinds\", and ignores the branches that are marked\n as such.\n\nI am a bit unhappy that subsequent fetches have to re-read the\nremote config every time. I can sort-of-see we can cram the\n\"this is expected to be rewound\" information as part of\npeek-remote exchange to avoid the overhead, but I do not think\nit is easily doable for dumb transports without breaking the\nbackward compatibility.\n\nTo avoid this, we need to remember what remote branches we have\nseen but decided not to track, perhaps because they were marked\nas \"rewinds\". Subsequent fetches first learn what are on the\nremote side, and only when it sees a branch that we do not track\nand we have not seen, it needs to re-read the remote config to\nsee if that is to be tracked (in which case we would create a\nnew tracking branch) or ignored (in which case we would remember\nthat we will ignore this branch in the future fetches).\n"},{"id":"297115","messageId":"200611261032.15207.jnareb@gmail.com","threadId":"43120","inReplyTo":"20061126033433.GD29394@spearce.org","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-26T09:32:14Z","receivedAt":"2006-11-26T09:32:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Shawn Pearce wrote:\n> Jakub Narebski wrote:\n>> Junio C Hamano wrote:\n>>\n>>> I am not sure if 'merge in corresponding branch' is the only\n>>> valid workflow, however. I am reluctant to make the system\n>>> automatically do so if the solution makes other workflows more\n>>> painful to follow. Automatically merging remotes/origin/$foo\n>>> when on $foo branch is not good enough, in other words (also,\n>>> there may be a hierarchy under remotes/ other than origin). It\n>>> might make sense to introduce \"Merge: \" in remotes/ file and if\n>>> they are present use \"Pull: \" only to decide what are fetched\n>>> and use \"Merge: \" to decide what is merged (if we were doing the\n>>> system from scratch, the former would have been named \"Fetch: \"\n>>> but it is too late now).\n>> \n>> If you add \"Merge: \" in remotes/, then please add it also in\n>> remote section in config file. Config file has now \n>> branch..merge (and it would be nice if clone would\n>> set ou this for local branches corresponding to remote branches),\n>> but it is not the same.\n> \n> I'm against adding anything to the remotes/ file format.\n> \n> We already have branch..merge to indicate what the default\n> source for a git-pull on the branch named should be.\n> git-branch probably should fill that entry in when a branch is\n> created from a remotes ref.\n\nAs I said, branch..merge is about something else: it just means\nthat if we are on branch \"git pull\" will merge \nbranch..merge branch into it.\n\nI think the \"Merge: \" or remote..merge is about changing current \nimplicit rule: first branch is to be merged with current branch (if not \nspecified otherwise) when pull-ing, into explicit rule: branch marked \nas \"Merge: \" is to be merged with current branch (unless specified \notherwise).\n\nCorrect me if I'm wrong, Junio.\n-- \nJakub Narebski\n"},{"id":"293876","messageId":"ekbnhe$naq$1@sea.gmane.org","threadId":"43120","inReplyTo":"7v1wnqwoxz.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-26T09:43:41Z","receivedAt":"2006-11-26T09:43:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n>  * Subsequent fetch, when the glob is not '+' variant, would\n>    download the config from the remote in order to see which are\n>    marked as \"rewinds\", and ignores the branches that are marked\n>    as such.\n> \n> I am a bit unhappy that subsequent fetches have to re-read the\n> remote config every time.  I can sort-of-see we can cram the\n> \"this is expected to be rewound\" information as part of\n> peek-remote exchange to avoid the overhead, but I do not think\n> it is easily doable for dumb transports without breaking the\n> backward compatibility.\n\nPerhaps below the \"Pull: refs/heads/*:refs/remotes/origin/*\" (or config\nequivalent) we should list (in some format) branches which are not to be\nfetched becaus they don't fast forward. One option, namely\n Pull:-refs/heads/pu:refs/remotes/origin/pu\n(or config equivalent)comes to mind. It has the advantage that when we\ndecide to fetch this branch, it would be as easy as changing '-' to '+'.\nOr we can use '!' instead of '-' if you think it is more readable (probably\nis).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297015","messageId":"200611270141.14307.Josef.Weidendorfer@gmx.de","threadId":"43120","inReplyTo":"7v1wnr19do.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-27T00:41:14Z","receivedAt":"2006-11-27T00:41:14Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Saturday 25 November 2006 22:53, Junio C Hamano wrote:\n> - merging the \"primary\" branch is good only when the user is on\n> the corresponding \"primary\" branch. It is usually a wrong\n> thing to do when on another branch.\n\nI vote for a config option\n\n core.pull.stopWithoutDefaultMerge\n\nwhich would error out on a\n\n git pull\n\nwhen no branch..merge is set with a message like\n\n \"No default remote branch set to merge into current branch .\n Set branch..remote/merge to make this work\"\n\nIt is arguable if this option should change the behavior of\n\"git pull \". Probably not: I would assume that the\nuser explicitly wants to merge the primary branch of .\n\nAdditionally, set branch..remote/merge on git-clone,\ntogether with core.pull.stopWithoutDefaultMerge=1.\n\n"},{"id":"297869","messageId":"200611270159.14925.Josef.Weidendorfer@gmx.de","threadId":"43120","inReplyTo":"7vvel2yi2u.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-27T00:59:14Z","receivedAt":"2006-11-27T00:59:14Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Sunday 26 November 2006 04:58, Junio C Hamano wrote:\n> > git-clone should skip rewinding branches by default, unless the user\n> > adds an option (e.g. --include-rewinding-branches). This way new\n> > users to git.git don't get the `pu` branch unless they really mean\n> > to get it, at which point they have hopefully also read the upstream's\n> > description of the `pu` branch and its rewinding policy, and can\n> > at least start to grasp what is going to happen if they start to\n> > work with the branch.\n> \n> I like this approach very much.\n\nI am not so sure about this. IMHO, any user expects to see \"pu\" branch\ncloned too after cloning git.git (at least me, and a newbie probably too).\n\nI agree about the remote branch description saying that \"pu\" branch will\nbe rewinded. git-clone should set \"+\" before such a branch.\n\nAs said, the real problem begins when the user tries to branch off her\nown local branch from \"pu\". At this point, \"git branch\" or\n\"git checkout -b ...\" should warn the user that he has to expect troubles\nwhen branching off from such a branch, and only allow it with a\n\"--force\" option.\n\n"},{"id":"295711","messageId":"7virh1r8f1.fsf@assigned-by-dhcp.cox.net","threadId":"43120","inReplyTo":"200611270159.14925.Josef.Weidendorfer@gmx.de","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-27T01:21:38Z","receivedAt":"2006-11-27T01:21:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer writes:\n\n> I am not so sure about this. IMHO, any user expects to see \"pu\" branch\n> cloned too after cloning git.git (at least me, and a newbie probably too).\n\nI think you are right that we can keep our sanity without\nomitting rewinding ones from the tracked set of branches. In\nfact, remotes/origin/* hierarchy are not to be checked out\ndirectly anyway, even after we do the \"bare SHA-1 stored in\n$GIT_DIR/HEAD\" update -- that should give you a read-only\ncheckout that you cannot commit on top of. As long as we warn\nusers who try to merge from these rewinding branches, there is\nno reason not to track them.\n\n> As said, the real problem begins when the user tries to branch off her\n> own local branch from \"pu\". At this point, \"git branch\" or\n> \"git checkout -b ...\" should warn the user that he has to expect troubles\n> when branching off from such a branch, and only allow it with a\n> \"--force\" option.\n\nThat is true if you make \"git branch my-pu remotes/origin/pu\" to\nsomehow set up the default merge source of \"my-pu\" branch to be\nremotes/origin/pu to encourage merging from it.\n\nI am still not convinced it is a valid assumption that a branch\noften want to merge from the branch it was forked off of, and\neven less so that \"git branch\" and \"git checkout -b\" are the\nplaces to do that configuration.\n\nBut for the sake of discussion let's pretend for now that it\nwere a good idea. If we know remotes/origin/pu is expected to\nbe rewound, the logic that configures \"my-pu\" to merge from the\nfork origin should be able to notice that situation, and refrain\nfrom doing the configuration, to prevent the user from issuing\n\"git pull\" without saying \"from where\", which can be done with\nyour merge.stopsansdefault option in your other message.\n\n"},{"id":"298573","messageId":"1164835956.4724.62.camel@cashmere.sps.mot.com","threadId":"43120","inReplyTo":"7v1wnr19do.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-11-29T21:32:36Z","receivedAt":"2006-11-29T21:32:36Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Sat, 2006-11-25 at 15:53, Junio C Hamano wrote:\n\n> I am not sure if 'merge in corresponding branch' is the only\n> valid workflow, however. I am reluctant to make the system\n> automatically do so if the solution makes other workflows more\n> painful to follow. Automatically merging remotes/origin/$foo\n> when on $foo branch is not good enough, in other words (also,\n> there may be a hierarchy under remotes/ other than origin). It\n> might make sense to introduce \"Merge: \" in remotes/ file and if\n> they are present use \"Pull: \" only to decide what are fetched\n> and use \"Merge: \" to decide what is merged (if we were doing the\n> system from scratch, the former would have been named \"Fetch: \"\n> but it is too late now).\n\nHeh. It was too late back here too!\n\n From: \tJon Loeliger \n To: \tGit List \n Subject: \tRe: GIT 0.99.7d, and end of week status.\n Date: \tMon, 26 Sep 2005 15:17:32 -0500\n Message-Id: <1127765852.5735.36.camel@cashmere.sps.mot.com>\n\njdl\n\n"},{"id":"295512","messageId":"1164910560.4724.117.camel@cashmere.sps.mot.com","threadId":"43120","inReplyTo":"7vvel2yi2u.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-11-30T18:16:01Z","receivedAt":"2006-11-30T18:16:01Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Sat, 2006-11-25 at 21:58, Junio C Hamano wrote:\n> Shawn Pearce writes:\n> \n> > Needing to put + in front of a refspec (or needing to fetch it with\n> > --force) is the user agreeing that something _evil_ is going on with\n> > the upstream and that they acknowledge this may cause problems for\n> > them locally.\n> >\n> > I would prefer to see the upstream be able to publish a short\n> > description of each branch, where the repository owner can describe\n> > the policy of that branch, as well as have a machine readable\n> > setting on each branch indicating if that branch will be rewound\n> > from time to time, or never rewound.\n> >\n> > git-clone should skip rewinding branches by default, unless the user\n> > adds an option (e.g. --include-rewinding-branches). This way new\n> > users to git.git don't get the `pu` branch unless they really mean\n> > to get it, at which point they have hopefully also read the upstream's\n> > description of the `pu` branch and its rewinding policy, and can\n> > at least start to grasp what is going to happen if they start to\n> > work with the branch.\n> \n> I like this approach very much.\n\nI see how it is! :-) When Shawn says it, it is to be liked.\nBut when I allude to it a _year_ ago, I'm ignored.\n\n\n From: Jon Loeliger \n To: git@vger.kernel.org\n Subject: Re: Trying to Update All Heads of a Repository\n Date: Fri, 4 Nov 2005 07:49:40 -0700 \n Message-ID: \n\n So, from the git-pull man page:\n\n For \"git push\", the local ref that matches is\n used to fast forward the remote ref that matches\n . If the optional plus + is used, the remote\n ref is updated even if it does not result in a fast\n forward update.\n\n Ah-ha! Wait. But here's the conceptual missing piece:\n When might I _know_ I have the situation where a\n fast-forward update might not happen? And as a remote\n puller, that would be \"never\" -- unless I know something\n about the nature of the remote end. That is, like you\n said, \"pu\" is subject to wild fluctuation and non-linear\n behavior. But any random puller can't know that a\n priori. So far, that is out-of-band information about a\n branch that needs to be \"available\".\n\nYep, out-of-band information that needs to be available indeed...\n\nAh well. :-)\n\njdl\n\n"},{"id":"298211","messageId":"7v64cwiq9k.fsf@assigned-by-dhcp.cox.net","threadId":"43120","inReplyTo":"1164910560.4724.117.camel@cashmere.sps.mot.com","subject":"Re: [RFD] making separate-remote layout easier to use","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-30T21:22:15Z","receivedAt":"2006-11-30T21:22:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger writes:\n\n> On Sat, 2006-11-25 at 21:58, Junio C Hamano wrote:\n>> > ...\n>> > I would prefer to see the upstream be able to publish a short\n>> > description of each branch, where the repository owner can describe\n>> > the policy of that branch,...\n>> ...\n>> I like this approach very much.\n>\n> I see how it is! :-) When Shawn says it, it is to be liked.\n> But when I allude to it a _year_ ago, I'm ignored.\n\nThink of it not as a difference between you and Shawn, but as a\ndifference in me back then and me now, who finally saw the light\nin your revelation after gaining a year's worth of experience ;-).\n\nSeriously, I did not ignore it, and I think some of your other\ncomments in the message contributed to improved documentation.\nWhen your message was posted, the issue Shawn raised in his\nmessage was not so prominent, because people did not even get\nthat \"Pull: refs/heads/pu:refs/heads/pu\" line in their remotes/\nfile by default back then. It was back in 0.99.9 era and a few\ndays after your message, a patch was posted to put more than\njust the 'master' mapping in the remotes/ file clone creates.\nIt became an issue after that change but we lacked the resources\nnor sense of urgency to do the out-of-band stuff, as we were\nbusy working on other things.\n"}]}