{"thread":{"id":"32849","subject":"Proposal: branch..remotepush","startedAt":"2013-02-07T16:14:59Z","lastAt":"2013-02-09T07:29:12Z","messageCount":25,"participants":["Ramkumar Ramachandra","Michael Schubert","Jonathan Nieder","Junio C Hamano","Jeff King","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"208923","messageId":"CALkWK0nA4hQ0VWivk3AVVVq8Rbb-9CpQ9xFsSOsTQtvo4w08rw@mail.gmail.com","threadId":"32849","inReplyTo":null,"subject":"Proposal: branch..remotepush","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-07T16:14:59Z","receivedAt":"2013-02-07T16:14:59Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nThis has been annoying me for a really long time, but I never really\ngot around to scratching this particular itch. I have a very common\nscenario where I fork a project on GitHub. I have two configured\nremotes: origin which points to \"git://upstream\" and mine which points\nto \"ssh://mine\". By default, I always want to pull `master` from\norigin and push to mine. Unfortunately, there's only a\nbranch..remote which specifies which remote to use for both\npulling and pushing. There's also a remote..pushurl, but I get\nthe feeling that this exists for an entirely different reason: when I\nhave a server with a highly-available read-only mirror of the\nrepository at git://anongit.*, and a less-available committer-only\nmirror at ssh://*.\n\nHow about a branch..remotepush that specifies a special remote\nfor pushing, falling back to branch..remote?\n\nRam\n"},{"id":"208924","messageId":"5113E849.8000602@elegosoft.com","threadId":"32849","inReplyTo":"CALkWK0nA4hQ0VWivk3AVVVq8Rbb-9CpQ9xFsSOsTQtvo4w08rw@mail.gmail.com","subject":"Re: Proposal: branch..remotepush","fromName":"Michael Schubert","fromEmail":"mschub@elegosoft.com","sentAt":"2013-02-07T17:45:45Z","receivedAt":"2013-02-07T17:45:45Z","isPatch":false,"sender":{"key":"mschub@elegosoft.com","avatar":null},"body":"On 02/07/2013 05:14 PM, Ramkumar Ramachandra wrote:\n\n> This has been annoying me for a really long time, but I never really\n> got around to scratching this particular itch. I have a very common\n> scenario where I fork a project on GitHub. I have two configured\n> remotes: origin which points to \"git://upstream\" and mine which points\n> to \"ssh://mine\". By default, I always want to pull `master` from\n> origin and push to mine. Unfortunately, there's only a\n> branch..remote which specifies which remote to use for both\n> pulling and pushing. There's also a remote..pushurl, but I get\n> the feeling that this exists for an entirely different reason: when I\n> have a server with a highly-available read-only mirror of the\n> repository at git://anongit.*, and a less-available committer-only\n> mirror at ssh://*.\n> \n> How about a branch..remotepush that specifies a special remote\n> for pushing, falling back to branch..remote?\n\nAdditionally, it would be nice to have branch..push or similar\nto configure a default destination branch for push. Gerrit users usually\nwant to track refs/heads/master but push to refs/for/master for example.\n"},{"id":"208938","messageId":"CALkWK0=53riU3xKbKkyAVS8--9VoAU5P6h88MQ9-geW=H5+a-w@mail.gmail.com","threadId":"32849","inReplyTo":"5113E849.8000602@elegosoft.com","subject":"Re: Proposal: branch..remotepush","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-07T19:37:04Z","receivedAt":"2013-02-07T19:37:04Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"There's a reason why remote..pushurl feels wrong. If one remote\nhas a different push from pull, there should be something\ncorresponding to refs/remotes/* for push (and the equivalent of fetch\nfor updating it). Second, I can't even diff between a branch on my\npush URL and a local branch: the [ahead 1, behind 1] in status output\nreally doesn't make sense if the repository you're pushing to is\ndifferent from the one you're pulling from. In contrast, if you take\nwhat I proposed, refs/remotes/{upstream, mine}/* already exist, and\nit's easy to diff them with the corresponding local branch.\n\nAnd yes, a regular `git push origin refs/for/master` is just retarded.\n I don't personally use Gerrit, but the people who do should not have\nto suffer.\n"},{"id":"208940","messageId":"CALkWK0=_0hZP_SjMCjooUAr+MrRoXCCzdQF8y9RhW1g7ShsC7w@mail.gmail.com","threadId":"32849","inReplyTo":"CALkWK0=53riU3xKbKkyAVS8--9VoAU5P6h88MQ9-geW=H5+a-w@mail.gmail.com","subject":"Re: Proposal: branch..remotepush","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-07T19:49:57Z","receivedAt":"2013-02-07T19:49:57Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> And yes, a regular `git push origin refs/for/master` is just retarded.\n\nActually a git config remote.origin.push refs/heads/*:refs/for/* makes\nmore sense here.\n"},{"id":"208942","messageId":"CALkWK0k=k5P8gL-1gNXQ4gO7uNiw9QUUqWrbuf8=iUFfn=TRNg@mail.gmail.com","threadId":"32849","inReplyTo":"CALkWK0=_0hZP_SjMCjooUAr+MrRoXCCzdQF8y9RhW1g7ShsC7w@mail.gmail.com","subject":"Re: Proposal: branch..remotepush","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-07T20:14:49Z","receivedAt":"2013-02-07T20:14:49Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Ramkumar Ramachandra wrote:\n>> And yes, a regular `git push origin refs/for/master` is just retarded.\n>\n> Actually a git config remote.origin.push refs/heads/*:refs/for/* makes\n> more sense here.\n\nSorry about all that confusion. The first line should be `git push\norigin master:refs/for/master`, but a rule like refs/head/*:refs/for/*\nis insufficient: what if I want refs/head/*:refs/heads/* for one set\nof branches (private ones that I don't send for review), and\nrefs/heads/*:refs/for/* for another set (which I send for review)?\nThat certainly won't play well will the existing remote.origin.push;\nit'd have to behave as an override.\n"},{"id":"208955","messageId":"20130207233017.GD19397@google.com","threadId":"32849","inReplyTo":"CALkWK0=53riU3xKbKkyAVS8--9VoAU5P6h88MQ9-geW=H5+a-w@mail.gmail.com","subject":"Re: Proposal: branch..remotepush","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-07T23:30:17Z","receivedAt":"2013-02-07T23:30:17Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Ram,\n\nRamkumar Ramachandra wrote:\n\n> And yes, a regular `git push origin refs/for/master` is just retarded.\n\nThe usual incantation is \"git push gerrit HEAD:refs/for/master\". Is\nthe code review creation push that uses a different branchname from\nthe branch the integrator pulls what seems backward, or is it the need\nto specify a refname at all on the command line?\n\nI agree that a \"[branch \"master\"] pushremote\" configuration would be\nhandy. pushremote instead of remotepush to be less surprising to\npeople who have already seen pushurl.\n\nGood luck,\nJonathan\n"},{"id":"208957","messageId":"7v38x766b2.fsf@alter.siamese.dyndns.org","threadId":"32849","inReplyTo":"20130207233017.GD19397@google.com","subject":"Re: Proposal: branch..remotepush","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-07T23:41:05Z","receivedAt":"2013-02-07T23:41:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> The usual incantation is \"git push gerrit HEAD:refs/for/master\". Is\n> the code review creation push that uses a different branchname from\n> the branch the integrator pulls what seems backward, or is it the need\n> to specify a refname at all on the command line?\n>\n> I agree that a \"[branch \"master\"] pushremote\" configuration would be\n> handy. pushremote instead of remotepush to be less surprising to\n> people who have already seen pushurl.\n\nI'd actually see this as Gerrit being weird.\n\nIf it wants to quarantine a commit destined to the \"master\" branch,\ncouldn't it just let people push to \"master\" and then internally\nupdate \"for/master\" instead?\n"},{"id":"208972","messageId":"20130208044836.GC4157@sigill.intra.peff.net","threadId":"32849","inReplyTo":"CALkWK0nA4hQ0VWivk3AVVVq8Rbb-9CpQ9xFsSOsTQtvo4w08rw@mail.gmail.com","subject":"Re: Proposal: branch..remotepush","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-08T04:48:36Z","receivedAt":"2013-02-08T04:48:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:\n\n> This has been annoying me for a really long time, but I never really\n> got around to scratching this particular itch. I have a very common\n> scenario where I fork a project on GitHub. I have two configured\n> remotes: origin which points to \"git://upstream\" and mine which points\n> to \"ssh://mine\". By default, I always want to pull `master` from\n> origin and push to mine.\n\nSame here. Even without GitHub, working on git.git I treat Junio as my\n\"origin\", but push to a publishing point.\n\n> Unfortunately, there's only a branch..remote which specifies\n> which remote to use for both pulling and pushing. There's also a\n> remote..pushurl, but I get the feeling that this exists for an\n> entirely different reason: when I have a server with a\n> highly-available read-only mirror of the repository at\n> git://anongit.*, and a less-available committer-only mirror at\n> ssh://*.\n\nYeah, you don't want to use pushurl. It makes the assumption that you\nare pushing to the same remote, so when you, e.g., push to the remote's\nrefs/heads/master, it will update refs/remotes/origin/master. But that's\nnot right; that ref should be tracking the true origin, not what you\npushed to.\n\n> How about a branch..remotepush that specifies a special remote\n> for pushing, falling back to branch..remote?\n\nSure, though I wonder if you really want a per-branch config, or if you\njust want remote.pushDefault or similar, so that you do not have to\nconfigure each branch independently as you create it. I'm imagining\nlookup rules something like:\n\n 1. If we are on branch $b, check branch.$b.pushRemote.\n\n 2. If not set, check remote.pushDefault.\n\n 3. If not set, check branch.$b.remote.\n\n 4. If not set, check remote.default (there was a proposal for this a\n few months ago, but it got stalled).\n\n 5. If not set, use \"origin\".\n\nAnd then fetching could do the same, with s/push/fetch/. In both cases,\nif you are not using the new variables, the behavior is the same as\nthe current behavior.\n\n-Peff\n"},{"id":"208976","messageId":"7vliaz49sf.fsf@alter.siamese.dyndns.org","threadId":"32849","inReplyTo":"20130208044836.GC4157@sigill.intra.peff.net","subject":"Re: Proposal: branch..remotepush","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-08T06:08:48Z","receivedAt":"2013-02-08T06:08:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:\n>\n>> This has been annoying me for a really long time, but I never really\n>> got around to scratching this particular itch. I have a very common\n>> scenario where I fork a project on GitHub. I have two configured\n>> remotes: origin which points to \"git://upstream\" and mine which points\n>> to \"ssh://mine\". By default, I always want to pull `master` from\n>> origin and push to mine.\n>\n> Same here. Even without GitHub, working on git.git I treat Junio as my\n> \"origin\", but push to a publishing point.\n\nThe \"you fetch from and push to the same place\" semantics that\nassociates a branch to a single remote was primarily done for people\ncoming from CVS/SVN background [*1*]. I think the triangle\narrangement where you want to have \"this is where I fetch from and\nintegrate with, and that is where I publish\" is more common among\nthe Git users these days.\n\nHow best to express the triangle is somewhat tricky, but I think it\nis sensible to say you have \"origin\" that points to your upstream\n(i.e. me), and \"peff\" that points to your publishing point, in other\nwords, make it explicit that the user deals with two remotes. Then\nhave push.default name the remote \"peff\", so that \"git push\" goes to\nthat remote by default (and have \"git fetch/pull\" go to \"origin).\nYou will have two sets of remote tracking branches (one from \"origin\"\nthat your push will never pretend to have fetched immediately after\nfinishing, the other from \"peff\" that keeps track of what you pushed\nthe last time).\n\nOf course, some people may have \"I use this and that branches to\ninteract with upstream X while I use these other branches to\ninteracct with upstream Y, and all of them push to different\nplaces\", and supporting that may need complex per branch \"On this\nbranch fetch from and integrate with remote X, and push to remote Z\"\nsettings, but as you said, \"I fetch from and integrate with X, and\nresult is pushed out to Y\" should be the most common, and it would\nbe desirable to have a simple way to express it with just a single\nnew configuration variable.\n\n\n[Footnote]\n\n*1* It also happens to work reasonably well for people like Linus\nand I with the \"I pull from random places, I locally integrate and I\npublish the results\" workflow, because we are trained to think that\nit is not just being lazy but simply meaningless to say \"git pull\"\nwithout saying \"fetch and integrate _what_ and from _whom_\", and\nthat is only because we do not have a fixed upstream. Linus and I\nwould practically never fetch from \"origin\", i.e. from ourselves.\n"},{"id":"208981","messageId":"20130208062855.GA12271@sigill.intra.peff.net","threadId":"32849","inReplyTo":"7vliaz49sf.fsf@alter.siamese.dyndns.org","subject":"Re: Proposal: branch..remotepush","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-08T06:28:56Z","receivedAt":"2013-02-08T06:28:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 07, 2013 at 10:08:48PM -0800, Junio C Hamano wrote:\n\n> How best to express the triangle is somewhat tricky, but I think it\n> is sensible to say you have \"origin\" that points to your upstream\n> (i.e. me), and \"peff\" that points to your publishing point, in other\n> words, make it explicit that the user deals with two remotes. Then\n> have push.default name the remote \"peff\", so that \"git push\" goes to\n> that remote by default (and have \"git fetch/pull\" go to \"origin).\n> You will have two sets of remote tracking branches (one from \"origin\"\n> that your push will never pretend to have fetched immediately after\n> finishing, the other from \"peff\" that keeps track of what you pushed\n> the last time).\n\nExactly. That is what I have set up now, except that I have to type \"git\npush peff\" because there is no such push.default (with the minor nit\nthat push.default does something else, so the config should be called\nremote.pushDefault or something). The entirety of the feature would be\nsaving the user from the annoyance of:\n\n $ git push\n fatal: remote error:\n You can't push to git://github.com/gitster/git.git\n Use git@github.com:gitster/git.git\n\n [doh! Stupid git, why don't you do what I mean, not what I say?]\n $ git push peff\n ... it works ...\n\n> Of course, some people may have \"I use this and that branches to\n> interact with upstream X while I use these other branches to\n> interacct with upstream Y, and all of them push to different\n> places\", and supporting that may need complex per branch \"On this\n> branch fetch from and integrate with remote X, and push to remote Z\"\n> settings, but as you said, \"I fetch from and integrate with X, and\n> result is pushed out to Y\" should be the most common, and it would\n> be desirable to have a simple way to express it with just a single\n> new configuration variable.\n\nRight. Frankly, I do not care that much about the per-branch push remote\nmyself. In the rules I gave earlier, that was my complete\nbackwards-compatible vision, so that we do not paint ourselves into a\ncorner compatibility-wise when somebody wants it later. Just\nimplementing the default push remote part would be a fine first step.\n\nI also indicated in my rules that we could have a branch.*.fetchRemote,\nas well, but I do not think it is strictly necessary. I think the\nnon-specific branch.*.remote could continue to be used for fetching, and\nas a backup when the push-specific variables are not set.\n\n> *1* It also happens to work reasonably well for people like Linus\n> and I with the \"I pull from random places, I locally integrate and I\n> publish the results\" workflow, because we are trained to think that\n> it is not just being lazy but simply meaningless to say \"git pull\"\n> without saying \"fetch and integrate _what_ and from _whom_\", and\n> that is only because we do not have a fixed upstream. Linus and I\n> would practically never fetch from \"origin\", i.e. from ourselves.\n\nRight, I think \"git pull\" is more useful in a centralized repo setting\nwhere there is one branch and one repo, so there is no \"what and whom\"\nto specify. Personally I do not use it much at all, as I do a separate\nfetch, inspect, and merge, but that is somewhat orthogonal to your\nreasons. :)\n\n-Peff\n"},{"id":"208982","messageId":"7vd2wb483w.fsf@alter.siamese.dyndns.org","threadId":"32849","inReplyTo":"7vliaz49sf.fsf@alter.siamese.dyndns.org","subject":"Re: Proposal: branch..remotepush","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-08T06:45:07Z","receivedAt":"2013-02-08T06:45:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> .... I think the triangle\n> arrangement where you want to have \"this is where I fetch from and\n> integrate with, and that is where I publish\" is more common among\n> the Git users these days.\n\nAnother thing to know about is that the recent move to change the\nbehaviour of \"git push\" to work only on one branch per default may\nhave to be polished and strengthened a bit.\n\nOriginally, the encouraged workflow was to perfect _everything_ that\nyou would push out and then with a single \"git push\" to publish\neverything at the same time. Both the \"matching\" behaviour of \"git\npush\" which was the default, and the set of push refspecs that is to\nbe defined per remote, were ways to discourage \"Work on one branch,\nthink it is OK, hastily push only that branch out, switch to another\nbranch, rinse, repeat\".\n\nTo support a triangular arrangement well, there may need some\nthinking on what $branch@{upstream} means. The original intent of\nthe upstream mode specified for \"push.default\" is push the result\nback to what you based your work on, but in a triangular arrangement\nthat is no longer true. You may be keeping up with my 'master' by\nconstantly rebasing and then pushing out the result to your 'frotz'\ntopic. You want to have a lazy \"git fetch\" to fetch from my\n'master' (i.e. upstream), and have remotes/origin/master to keep\ntrack of it. You want to see \"git rebase\" to pay attention to the\nupdates to remotes/origin/master when figuring out where you forked.\nBut at the same time, you want a lazy \"git push\" to go to your\npush.defaultTo repository (i.e. your publish point) and update your\n'frotz' branch there---remotes/origin/master should not come into\nthe picture at all. But the upstream and simple modes want to pay\nattention to branch.$name.merge, which is all about the \"fetch and\nintegrate\" side of the equation.\n"},{"id":"208985","messageId":"20130208074813.GA7337@elie.Belkin","threadId":"32849","inReplyTo":"7v38x766b2.fsf@alter.siamese.dyndns.org","subject":"Re: Proposal: branch..remotepush","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-08T07:48:13Z","receivedAt":"2013-02-08T07:48:13Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> I'd actually see this as Gerrit being weird.\n>\n> If it wants to quarantine a commit destined to the \"master\" branch,\n> couldn't it just let people push to \"master\" and then internally\n> update \"for/master\" instead?\n\nIt is because pushing doesn't update refs/heads/master. Instead, it\nstarts a code review.\n\nSuppose Gerrit allows starting a new code review by pushing to\nrefs/heads/master. It sounds okay if I squint --- it's just a very\nslow asynchronous ref update, right? Let's see:\n\n\t$ git clone test\n\tCloning into 'test'...\n\t$ echo hi >greeting\n\t$ git add greeting\n\t$ git commit -q -m 'hello'\n\t$ git push origin master\n[...]\n\tremote: New Changes:\n\tremote: /r/1234\n\tremote: \n\tTo \n\t ea4cb77b..9117390e master -> master\n\t$ : walk away, forget what I was doing\n\t$ git fetch origin\n\tFrom \n\t + 9117390...ea4cb77 master -> origin/master (forced update)\n\n\"Wait, why did the remote rewind?\"\n\nRegards,\nJonathan\n"},{"id":"208986","messageId":"7v622343uy.fsf@alter.siamese.dyndns.org","threadId":"32849","inReplyTo":"20130208074813.GA7337@elie.Belkin","subject":"Re: Proposal: branch..remotepush","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-08T08:16:53Z","receivedAt":"2013-02-08T08:16:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> \"Wait, why did the remote rewind?\"\n\nOh, I am very well aware of that glitch.\n\n\"git push\" has this hack to pretend as if the pusher immediately\nturned around and fetched from the remote.\n\nIt shouldn't have been made to do so unconditionally; instead it\nshould have been designed to give the pushee a way to optionally\ntell you \"I acccept this push, but you may not see it to be updated\nto that exact value you pushed when you fetched from me right now\".\n\nThe hack is not my design; it was not even something I accepted\nwithout complaints, so I can badmouth about it all I want without\nhesitation ;-)\n\nMore importantly, we could fix it if we wanted to.\n"},{"id":"208989","messageId":"20130208092204.GA15490@sigill.intra.peff.net","threadId":"32849","inReplyTo":"7vd2wb483w.fsf@alter.siamese.dyndns.org","subject":"Re: Proposal: branch..remotepush","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-08T09:22:04Z","receivedAt":"2013-02-08T09:22:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 07, 2013 at 10:45:07PM -0800, Junio C Hamano wrote:\n\n> To support a triangular arrangement well, there may need some\n> thinking on what $branch@{upstream} means. The original intent of\n> the upstream mode specified for \"push.default\" is push the result\n> back to what you based your work on, but in a triangular arrangement\n> that is no longer true.\n\nI don't think that \"upstream\" or \"simple\" push settings really make\nsense in such a triangular arrangement. And IMHO, that's OK. They\nreflect a much simpler view of the world than git is capable of\nsupporting. So \"simple\" works OK as a default, and people can move to\n\"matching\" (or \"current\", or even a custom refspec) once they have are\nready to take advantage of a more advanced topology/workflow.\n\nWe have the problem now that new users do not necessarily understand the\nmatching strategy, or why it is useful, and get confused. When we move\nto \"simple\", we may be switching to a world where the early part of the\nlearning curve is more gentle for those users, but they eventually run\nacross the steeper part when they want to adjust their workflow (i.e.,\nthey will eventually learn about non-symmetric repo topologies because\nthose are part of many useful workflows).\n\nBut I think it's a good thing to push that part of the learning curve\nout, because:\n\n 1. Some people may stay in the centralized view their whole lives and\n never care.\n\n 2. It will make more sense to them, because they'll understand how it\n fits into what they're trying to do, rather than viewing it as an\n arcane and senseless default.\n\nThere may be some confusion as people hit that learning point. I won't\nbe surprised if we end up adding more advice.* messages in certain cases\nto guide people to adjusting their push.default. But I'm just as happy\nto wait until people start hitting the confusion point in practice, and\nwe can see more clearly when that advice should trigger, and what it\nshould say.\n\nUnless you have ideas now, of course, in which case I'm happy to hear\nthem. :)\n\n-Peff\n"},{"id":"208992","messageId":"5114D5B0.5080906@drmicha.warpmail.net","threadId":"32849","inReplyTo":"7v622343uy.fsf@alter.siamese.dyndns.org","subject":"Re: Proposal: branch..remotepush","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-02-08T10:38:40Z","receivedAt":"2013-02-08T10:38:40Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:\n> Jonathan Nieder writes:\n> \n>> \"Wait, why did the remote rewind?\"\n> \n> Oh, I am very well aware of that glitch.\n> \n> \"git push\" has this hack to pretend as if the pusher immediately\n> turned around and fetched from the remote.\n> \n> It shouldn't have been made to do so unconditionally; instead it\n> should have been designed to give the pushee a way to optionally\n> tell you \"I acccept this push, but you may not see it to be updated\n> to that exact value you pushed when you fetched from me right now\".\n> \n> The hack is not my design; it was not even something I accepted\n> without complaints, so I can badmouth about it all I want without\n> hesitation ;-)\n> \n> More importantly, we could fix it if we wanted to.\n\nAnd this seems to be more natural, too. It can keep the internals (the\nauxiliary ref on the server side) hidden from the user.\n\nAs for the triangle remote, I really think we should clean up the\nsituation regarding push, pushurlinsteadof and the various different and\ninconclusive output formats of \"git remote\" (with or without \"-v\", with\nor without a remote name) first, before introducing yet another way to\ntwist things around. \"git push downstream\" does not hurt any kittens\n(while git remote ouput does, somehwat).\n\nMichael\n"},{"id":"209002","messageId":"7vwqui3fcc.fsf@alter.siamese.dyndns.org","threadId":"32849","inReplyTo":"20130208092204.GA15490@sigill.intra.peff.net","subject":"Re: Proposal: branch..remotepush","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-08T17:06:27Z","receivedAt":"2013-02-08T17:06:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> We have the problem now that new users do not necessarily understand the\n> matching strategy, or why it is useful, and get confused. When we move\n> to \"simple\", we may be switching to a world where the early part of the\n> learning curve is more gentle for those users, but they eventually run\n> across the steeper part when they want to adjust their workflow (i.e.,\n> they will eventually learn about non-symmetric repo topologies because\n> those are part of many useful workflows).\n>\n> But I think it's a good thing to push that part of the learning curve\n> out, because:\n>\n> 1. Some people may stay in the centralized view their whole lives and\n> never care.\n>\n> 2. It will make more sense to them, because they'll understand how it\n> fits into what they're trying to do, rather than viewing it as an\n> arcane and senseless default.\n>\n> There may be some confusion as people hit that learning point. I won't\n> be surprised if we end up adding more advice.* messages in certain cases\n> to guide people to adjusting their push.default. But I'm just as happy\n> to wait until people start hitting the confusion point in practice, and\n> we can see more clearly when that advice should trigger, and what it\n> should say.\n\nOh, I agree with you that adding new support for triangular workflow\nwill not hurt the centralized folks. I was more interested about\nhelping the \"fetch from here, push to there\" people.\n\nCentralized people do not have to configure anything for each branch\nfor \"git push\" to push their current branch to where they fetch from\nand to the same name (you start building on their 'master', your\nresult go to their 'master', because as a centralized person, you\nare part of 'them'). They have branch.$name.merge that names what\ntheir $name branch merges with, and that is sufficient to decide to\nwhich branch the result is to be pushed back. \n\nWith the \"push.defaultTo = peff\" to name what remote the \"git push\"\nwill push to, or even with the \"branch.master.remotepush = peff\" to\ndecide that per branch, would \"fetch from here, push to there\"\npeople have a way similar to what branch.$name.merge gives to the\ncentralized people to decide what branch is updated?\n\nIt almost seems to me that we may want to extend the semantics given\nto the remote.$name.push refspecs. They are primarily for \"perfect\nall branches you are going to push out, and push them in one go with\n'git push'\" workflow, but if it is clear that you are not following\nthat (e.g. you are doing an equivalent of what the centralized folks\nwould do with \"push.default = simple/upstream/current\") and pushing\nonly the current branch, perhaps we should look at these refspecs to\nsee where the current branch goes?\n\nIn your case, 'refs/heads/master' would likely to go to\n'refs/heads/master', and we could treat a missing remote.peff.push \nan equivalent to having remote.peff.push = refs/heads/*:refs/heads/*\n\nIn a Gerrit user's case brought up by Michael Schubert in a message\nearlier in the near-by subthread, 'refs/heads/frotz' would likely to\ngo to 'refs/for/frotz' and they can express it with something like\n\n\t[remote \"origin\"]\n\t\turl = ... ;# pushurl is the same or just s/git/ssh/;\n fetch = refs/heads/*:refs/heads/*\n push = refs/heads/*:refs/for/*\n\t[push]\n\t\tdefault = \"???\"\n\nwhere \"???\" says \"I push out only the currently checked-out branch;\nfigure out where it goes using remote.origin.push refspec\".\n\nHaving to set both branch.$name.remotepush to name what remote this\nbranch should be pushed, and branch.$name.branchpush to name what\nbranch at the remote this branch should update with a push, and\ndoing so for each and every branch, sounds like an unnecessary\ncomplexity.\n"},{"id":"209003","messageId":"7vsj563f3z.fsf@alter.siamese.dyndns.org","threadId":"32849","inReplyTo":"5114D5B0.5080906@drmicha.warpmail.net","subject":"Re: Proposal: branch..remotepush","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-08T17:11:28Z","receivedAt":"2013-02-08T17:11:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> As for the triangle remote, I really think we should clean up the\n> situation regarding push, pushurlinsteadof and the various different and\n> inconclusive output formats of \"git remote\" (with or without \"-v\", with\n> or without a remote name) first, before introducing yet another way to\n> twist things around. \"git push downstream\" does not hurt any kittens\n> (while git remote ouput does, somehwat).\n\nAs people tend to fetch more often than they push if they are\nworking on a real project where the others as a whole will be far\nmore productive than any single individual, I agree that keeping\n\"git fetch\" (or \"git pull\") lazy by having \"origin\" point at where\nthey fetch from and be a bit more explicit in \"git push\" would\nactually make sense.\n"},{"id":"209004","messageId":"7vobfu3ev3.fsf@alter.siamese.dyndns.org","threadId":"32849","inReplyTo":"5114D5B0.5080906@drmicha.warpmail.net","subject":"Re: Proposal: branch..remotepush","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-08T17:16:48Z","receivedAt":"2013-02-08T17:16:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:\n>> Jonathan Nieder writes:\n>> \n>>> \"Wait, why did the remote rewind?\"\n>> \n>> Oh, I am very well aware of that glitch.\n>> \n>> \"git push\" has this hack to pretend as if the pusher immediately\n>> turned around and fetched from the remote.\n>> \n>> It shouldn't have been made to do so unconditionally; instead it\n>> should have been designed to give the pushee a way to optionally\n>> tell you \"I acccept this push, but you may not see it to be updated\n>> to that exact value you pushed when you fetched from me right now\".\n>> \n>> The hack is not my design; it was not even something I accepted\n>> without complaints, so I can badmouth about it all I want without\n>> hesitation ;-)\n>> \n>> More importantly, we could fix it if we wanted to.\n>\n> And this seems to be more natural, too. It can keep the internals (the\n> auxiliary ref on the server side) hidden from the user.\n\nFixing that misfeature to always pretend it immediately turned\naround and fetched may have a different benefit, too.\n\nA straightforward and simple solution to Ram's original problem may\nbe to define pushurl to point at his publishing repository after\nall, and teach \"git push\" not to pretend it immediately fetched with\nthe same \"fix\".\n\n\t[remote \"origin\"]\n \turl = ... where Ram fetches and pulls from ...\n pushurl = ... where Ram pushes to ...\n fetch = refs/heads/*:refs/remotes/*\n\t\tupdateTrackOnPush = no\n\nThen \"git fetch\" (or \"git pull\") will update the remote tracking\nbranches Ram fetches from, and once his topic is finished, he can\npush to his publishing location, which won't touch the remote\ntracking branches used to keep track of the place he fetches from.\n"},{"id":"209012","messageId":"CALkWK0=RmKaM+5TRUxsPWomu+FgmAnBFBWe3YN+HFac4gnCqnA@mail.gmail.com","threadId":"32849","inReplyTo":"7vwqui3fcc.fsf@alter.siamese.dyndns.org","subject":"Re: Proposal: branch..remotepush","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-08T18:03:20Z","receivedAt":"2013-02-08T18:03:20Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Jeff King writes:\n>\n>> We have the problem now that new users do not necessarily understand the\n>> matching strategy, or why it is useful, and get confused. When we move\n>> to \"simple\", we may be switching to a world where the early part of the\n>> learning curve is more gentle for those users, but they eventually run\n>> across the steeper part when they want to adjust their workflow (i.e.,\n>> they will eventually learn about non-symmetric repo topologies because\n>> those are part of many useful workflows).\n>>\n>> But I think it's a good thing to push that part of the learning curve\n>> out, because:\n>>\n>> 1. Some people may stay in the centralized view their whole lives and\n>> never care.\n>>\n>> 2. It will make more sense to them, because they'll understand how it\n>> fits into what they're trying to do, rather than viewing it as an\n>> arcane and senseless default.\n>>\n>> There may be some confusion as people hit that learning point. I won't\n>> be surprised if we end up adding more advice.* messages in certain cases\n>> to guide people to adjusting their push.default. But I'm just as happy\n>> to wait until people start hitting the confusion point in practice, and\n>> we can see more clearly when that advice should trigger, and what it\n>> should say.\n>\n> Oh, I agree with you that adding new support for triangular workflow\n> will not hurt the centralized folks. I was more interested about\n> helping the \"fetch from here, push to there\" people.\n\nIn Git, there will always be a combination of switches which allows\nyou to go the centralized workflow mode. We're focusing on expanding\nthis list of switches, to free up distributed workflows into more\npossibilities. We're currently targeting problems that affect us\neveryday; the ones we've failed to notice.\n\n> Centralized people do not have to configure anything for each branch\n> for \"git push\" to push their current branch to where they fetch from\n> and to the same name (you start building on their 'master', your\n> result go to their 'master', because as a centralized person, you\n> are part of 'them'). They have branch.$name.merge that names what\n> their $name branch merges with, and that is sufficient to decide to\n> which branch the result is to be pushed back.\n\nWhat about the branch.$name.pushRef, which was proposed earlier? They\nshould be able to say, at a per-branch level, which branches to send\nfor review (in Gerrit).\n\n> With the \"push.defaultTo = peff\" to name what remote the \"git push\"\n> will push to, or even with the \"branch.master.remotepush = peff\" to\n> decide that per branch, would \"fetch from here, push to there\"\n> people have a way similar to what branch.$name.merge gives to the\n> centralized people to decide what branch is updated?\n\nAh.\n\n> It almost seems to me that we may want to extend the semantics given\n> to the remote.$name.push refspecs. They are primarily for \"perfect\n> all branches you are going to push out, and push them in one go with\n> 'git push'\" workflow, but if it is clear that you are not following\n> that (e.g. you are doing an equivalent of what the centralized folks\n> would do with \"push.default = simple/upstream/current\") and pushing\n> only the current branch, perhaps we should look at these refspecs to\n> see where the current branch goes?\n\nI'd actually just go with the current syntax + per-branch overrides.\nSimple and serves the purpose: I don't think there'll be real usecases\noutside this.\n\n> In your case, 'refs/heads/master' would likely to go to\n> 'refs/heads/master', and we could treat a missing remote.peff.push\n> an equivalent to having remote.peff.push = refs/heads/*:refs/heads/*\n\nI'll get to work on a patch that deems the configuration variable as\nnot \"necessary\".\n"},{"id":"209016","messageId":"CALkWK0nYRiPLnBXFarp8UzZgGvA5Y6motvr5HMFy56ANr161HA@mail.gmail.com","threadId":"32849","inReplyTo":"7vobfu3ev3.fsf@alter.siamese.dyndns.org","subject":"Re: Proposal: branch..remotepush","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-08T18:29:28Z","receivedAt":"2013-02-08T18:29:28Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> [remote \"origin\"]\n> url = ... where Ram fetches and pulls from ...\n> pushurl = ... where Ram pushes to ...\n> fetch = refs/heads/*:refs/remotes/*\n> updateTrackOnPush = no\n>\n> Then \"git fetch\" (or \"git pull\") will update the remote tracking\n> branches Ram fetches from, and once his topic is finished, he can\n> push to his publishing location, which won't touch the remote\n> tracking branches used to keep track of the place he fetches from.\n\nA \"push\" should never touch remote/refs/origin/* if there is a pushurl\nconfigured. Otherwise, it should. I want my push to affect my\nstatus. The configuration variable makes no sense and should not\nexist.\n\nUnfortunately, pushurl doesn't get the same privileges as url even\nthough they're equal remotes. How is my fork \"inferior\" to the\nupstream project in any way? A lot of us might be working on this\nfork, and we will need something corresponding to refs/remotes/* to\ninspect its state. Like I said earlier, I think pushurl has a very\nlimited usecase: when the two URLs are actually mirrors (there is\nreally no fork; we're back in a centralized environment). In fact, I\nthink it should be deprecated, because it interferes with my more\ngeneral approach.\n\nLet's see what happens if we have two actual remotes.\nremote/refs/origin/* will be updated when I fetch from, and push to,\norigin. remote/refs/ram/* will be updated when I fetch from, and\npush to, ram. It's very simple, and I don't need this complex rule of\nwhen to update refs. We should have a way to pair remotes together as\nupstream/ downstream in the future. Maybe even have a hierarchy of\nremotes.\n"},{"id":"209019","messageId":"20130208183629.GA8461@google.com","threadId":"32849","inReplyTo":"5114D5B0.5080906@drmicha.warpmail.net","subject":"Re: Proposal: branch..remotepush","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-08T18:36:29Z","receivedAt":"2013-02-08T18:36:29Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Michael J Gruber wrote:\n> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:\n>> Jonathan Nieder writes:\n\n>>> \"Wait, why did the remote rewind?\"\n>>\n>> Oh, I am very well aware of that glitch.\n>>\n>> \"git push\" has this hack to pretend as if the pusher immediately\n>> turned around and fetched from the remote.\n>> \n>> It shouldn't have been made to do so unconditionally; instead it\n>> should have been designed to give the pushee a way to optionally\n>> tell you \"I acccept this push, but you may not see it to be updated\n>> to that exact value you pushed when you fetched from me right now\".\n\nYes, I agree with this.\n\nThe \"git push\" hack does seem to be useful in practice for helping\npeople just starting to use git. If they have a separate \"gitk --all\"\nwindow open, they can refresh it and see the remote-tracking branch\ncorresponding to the branch that has been pushed advancing. It matches\na model in which remote-tracking refs represent \"git's idea of where\nthese branches are in the remote repository\".\n\nAnd in that model, a remote being able to respond to a push with\n\"ref update queued, but please keep in mind that it may take me a\nwhile to chew through that queue\" should be perfectly reasonable.\n\n[...]\n> And this seems to be more natural, too. It can keep the internals (the\n> auxiliary ref on the server side) hidden from the user.\n\nJust to clarify: this is not an internal ref being exposed. No\nauxiliary refs/for/master ref actually exists. The ref Gerrit users\npush to is a UI fiction.\n\nThat's important because otherwise two developers could not propose\nchanges for the same branch at the same time.\n\nJonathan\n"},{"id":"209020","messageId":"CALkWK0kR-KWJbG_kWSf7+JMJEQc7vO0Emx=_yogCB0jMBfccAg@mail.gmail.com","threadId":"32849","inReplyTo":"20130207233017.GD19397@google.com","subject":"Re: Proposal: branch..remotepush","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-08T18:42:16Z","receivedAt":"2013-02-08T18:42:16Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> Ramkumar Ramachandra wrote:\n>\n>> And yes, a regular `git push origin refs/for/master` is just retarded.\n>\n> The usual incantation is \"git push gerrit HEAD:refs/for/master\". Is\n> the code review creation push that uses a different branchname from\n> the branch the integrator pulls what seems backward, or is it the need\n> to specify a refname at all on the command line?\n\nHow else would you design a system to differentiate between a\npush-for-review, and push-to-update-ref?\n\nOn a slightly unrelated note, it would be nice if we could streamline\nthe git-format-patch, git-send-email process. Let's say we make it a\npush', which has a pre-hook that fires up the $EDITOR for a cover\nletter. Wouldn't you love it if this push' would update refs on your\nprivate fork and fire off emails to the Git List? Bonus for contrib/:\nfetch the Google address book, and allow me to auto-complete names\nwhen sending emails.\n\n> I agree that a \"[branch \"master\"] pushremote\" configuration would be\n> handy. pushremote instead of remotepush to be less surprising to\n> people who have already seen pushurl.\n\nThanks for that, by the way (used in RFC patch). My taste in variable\nnames is a little sour.\n"},{"id":"209023","messageId":"7vobfu1uvd.fsf@alter.siamese.dyndns.org","threadId":"32849","inReplyTo":"CALkWK0nYRiPLnBXFarp8UzZgGvA5Y6motvr5HMFy56ANr161HA@mail.gmail.com","subject":"Re: Proposal: branch..remotepush","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-08T19:13:58Z","receivedAt":"2013-02-08T19:13:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Junio C Hamano wrote:\n>> [remote \"origin\"]\n>> url = ... where Ram fetches and pulls from ...\n>> pushurl = ... where Ram pushes to ...\n>> fetch = refs/heads/*:refs/remotes/*\n>> updateTrackOnPush = no\n>>\n>> Then \"git fetch\" (or \"git pull\") will update the remote tracking\n>> branches Ram fetches from, and once his topic is finished, he can\n>> push to his publishing location, which won't touch the remote\n>> tracking branches used to keep track of the place he fetches from.\n>\n> A \"push\" should never touch remote/refs/origin/* if there is a pushurl\n> configured. Otherwise, it should.\n\nThat is a horrible design, no?\n\nBecause one of the main use case for pushurl is to use url = git://\nfor less overhead and pushurl = ssh+git:// for authentication but\notherwise going to the same place. So if \"git push\" is allowed to\npretend you immediately turned around and fetched, push to that\npushurl will pretend it was followed by a fetch from the\ncorresponding url.\n\nYou need a way to tell if the pushurl/url pair is used for that\npurpose to let Git know if that is the case.\n"},{"id":"209024","messageId":"7vhalm1unu.fsf@alter.siamese.dyndns.org","threadId":"32849","inReplyTo":"CALkWK0kR-KWJbG_kWSf7+JMJEQc7vO0Emx=_yogCB0jMBfccAg@mail.gmail.com","subject":"Re: Proposal: branch..remotepush","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-08T19:18:29Z","receivedAt":"2013-02-08T19:18:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Jonathan Nieder wrote:\n>> Ramkumar Ramachandra wrote:\n>>\n>>> And yes, a regular `git push origin refs/for/master` is just retarded.\n>>\n>> The usual incantation is \"git push gerrit HEAD:refs/for/master\". Is\n>> the code review creation push that uses a different branchname from\n>> the branch the integrator pulls what seems backward, or is it the need\n>> to specify a refname at all on the command line?\n>\n> How else would you design a system to differentiate between a\n> push-for-review, and push-to-update-ref?\n\nYou don't have to.\n\nIf the reviewed result is merged on the server side and appear on\n'master', nobody has to push to update refs/heads/master.\n"},{"id":"209072","messageId":"CALkWK0nP8m+VY=FzWtxts8hXCBnnQAiD8VB3Krjz70xAt-HLFw@mail.gmail.com","threadId":"32849","inReplyTo":"7vhalm1unu.fsf@alter.siamese.dyndns.org","subject":"Re: Proposal: branch..remotepush","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-02-09T07:29:12Z","receivedAt":"2013-02-09T07:29:12Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Ramkumar Ramachandra writes:\n>\n>> Jonathan Nieder wrote:\n>>> Ramkumar Ramachandra wrote:\n>>>\n>>>> And yes, a regular `git push origin refs/for/master` is just retarded.\n>>>\n>>> The usual incantation is \"git push gerrit HEAD:refs/for/master\". Is\n>>> the code review creation push that uses a different branchname from\n>>> the branch the integrator pulls what seems backward, or is it the need\n>>> to specify a refname at all on the command line?\n>>\n>> How else would you design a system to differentiate between a\n>> push-for-review, and push-to-update-ref?\n>\n> You don't have to.\n>\n> If the reviewed result is merged on the server side and appear on\n> 'master', nobody has to push to update refs/heads/master.\n\nI'm sorry, I meant differentiating between push-for-review and\npush-for-personal-work.\n"}]}