{"thread":{"id":"27290","subject":"Separate default remotes for pulling and pushing","startedAt":"2011-05-07T08:10:14Z","lastAt":"2011-05-10T21:12:57Z","messageCount":14,"participants":["David Lee","Sverre Rabbelier","Jeff King","Junio C Hamano","Jay Soffian"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"167311","messageId":"1FDDE878-C81A-4318-836B-7F8BED51A981@gmail.com","threadId":"27290","inReplyTo":null,"subject":"Separate default remotes for pulling and pushing","fromName":"David Lee","fromEmail":"davidomundo@gmail.com","sentAt":"2011-05-07T08:10:14Z","receivedAt":"2011-05-07T08:10:14Z","isPatch":false,"sender":{"key":"davidomundo@gmail.com","avatar":null},"body":"Hello,\n\nI couldn't find a way to do this, but it seems it would be a fairly common use-case:\n\nI want to set up different default remotes for pushing and pulling so that I can pull from remote a using \"git pull\" and push to remote b using \"git push\". This is particularly useful when committing to projects on github, since you may only push to your fork, but you only want to pull updates from the original.\n\nRight now, I can either set the original as my default remote, in which case I must use \"git push myfork\", or I can set my fork as the default remote, in which case I must use \"git pull original\".\n\nPlease let me know if I'm overlooking a feature already present in git that allows me to have separate remotes for pull and push. Otherwise, I hope it gets implemented in the next version of git!\n\nThanks for reading,\nDavid"},{"id":"167314","messageId":"BANLkTinJDUa7sXjKHo81bG7KbnspxZ88oA@mail.gmail.com","threadId":"27290","inReplyTo":"1FDDE878-C81A-4318-836B-7F8BED51A981@gmail.com","subject":"Re: Separate default remotes for pulling and pushing","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-05-07T09:50:35Z","receivedAt":"2011-05-07T09:50:35Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sat, May 7, 2011 at 10:10, David Lee wrote:\n> I want to set up different default remotes for pushing and pulling\n\nSee 'git remote set-url --push' [0].\n\n[0] http://www.kernel.org/pub/software/scm/git/docs/git-remote.html\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"167473","messageId":"20110509081708.GA5871@sigill.intra.peff.net","threadId":"27290","inReplyTo":"BANLkTinJDUa7sXjKHo81bG7KbnspxZ88oA@mail.gmail.com","subject":"Re: Separate default remotes for pulling and pushing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-09T08:17:08Z","receivedAt":"2011-05-09T08:17:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, May 07, 2011 at 11:50:35AM +0200, Sverre Rabbelier wrote:\n\n> On Sat, May 7, 2011 at 10:10, David Lee wrote:\n> > I want to set up different default remotes for pushing and pulling\n> \n> See 'git remote set-url --push' [0].\n> \n> [0] http://www.kernel.org/pub/software/scm/git/docs/git-remote.html\n\nThat probably doesn't quite do what David wants. It's useful when the\nURL for pushing and pulling a particular repository are different.\n\nBut if I understand it correctly, David has two _separate_ repositories.\nAnd using remote.*.pushurl for that has some unwanted side effects,\nbecause the tracking ref namespace (i.e., \"remotes/origin/*\") is shared\nby both, even though their refs may not be at the same position.\n\nFor example, when pushing \"refs/heads/master\" to the remote, git will\nupdate \"refs/remotes/origin/master\" to the pushed value. But that ref is\nsupposed to reflect the value of the last fetch from his \"original\"\nrepository, and now it doesn't. The ref value will flip back and forth\nbetween what's in the two repositories as he pushes and fetches.\n\nI don't think there is currently a way to do what he wants. I think it\nwould be useful for certain workflows. As I see it, there are a few\npretty common setups for remotes:\n\n 1. Centralized; you push and pull from a single repo, shared with\n other developers. In this case, you call it \"origin\" and everything\n is easy.\n\n 2. Decentralized, you're the maintainer; you pull from other people or\n apply patches via email. When you push, you push out to some\n publishing point. You'd probably call your publishing point\n \"origin\" (though I think Junio calls kernel.org \"ko\" and just types\n \"git push ko\"). You never pull from some single place all the time,\n so you don't care about a shorthand for it.\n\n 3. Decentralized, you're a developer with a patch-based workflow; you\n fetch from the maintainer, then develop and submit patches via a\n mailing list. You call the maintainer's repo \"origin\" and pull from\n it automatically. You never push, so it doesn't matter that\n there's no shorthand.\n\n 4. Decentralized, you're a developer that publishes work via git. You\n call the upstream maintainer \"origin\", so fetches are convenient\n (and git does this for you at clone, after all). But pushing, even\n though you probably always push to the same central, does not have\n a convenient shorthand.\n\n This is David's case (and mine, and I suspect some other git\n developers who do enough work that they want to make it publicly\n available via git, or even just have backups). It's also encouraged\n by sites like github, where you might clone the upstream's\n repository, but then pushes your changes up to a personal \"fork\"\n to let others see and merge them.\n\nSo I think part of the reason we don't have such an option is that cases\n1-3 are so common. But it would be a nice convenience for people in case\n4.\n\n-Peff\n"},{"id":"167475","messageId":"D0FA0C3F-8DA8-4607-A0A6-F9AFAB3EC3CE@gmail.com","threadId":"27290","inReplyTo":"20110509081708.GA5871@sigill.intra.peff.net","subject":"Re: Separate default remotes for pulling and pushing","fromName":"David Lee","fromEmail":"davidomundo@gmail.com","sentAt":"2011-05-09T08:34:22Z","receivedAt":"2011-05-09T08:34:22Z","isPatch":false,"sender":{"key":"davidomundo@gmail.com","avatar":null},"body":"Hey Jeff,\n\nThanks for the super write-up.\n\n> That probably doesn't quite do what David wants. It's useful when the\n> URL for pushing and pulling a particular repository are different.\n> \n> But if I understand it correctly, David has two _separate_ repositories.\n> And using remote.*.pushurl for that has some unwanted side effects,\n> because the tracking ref namespace (i.e., \"remotes/origin/*\") is shared\n> by both, even though their refs may not be at the same position.\n> \n> For example, when pushing \"refs/heads/master\" to the remote, git will\n> update \"refs/remotes/origin/master\" to the pushed value. But that ref is\n> supposed to reflect the value of the last fetch from his \"original\"\n> repository, and now it doesn't. The ref value will flip back and forth\n> between what's in the two repositories as he pushes and fetches.\n\nI was actually using Sverre's recommendation with virtually no problems except for what you mention: the ref value flips back and forth.\n\n> 4. Decentralized, you're a developer that publishes work via git. You\n> call the upstream maintainer \"origin\", so fetches are convenient\n> (and git does this for you at clone, after all). But pushing, even\n> though you probably always push to the same central, does not have\n> a convenient shorthand.\n\nBy \"push to the same central\", I assume you mean \"push to the same mirror of origin\".\n\n> \n> This is David's case (and mine, and I suspect some other git\n> developers who do enough work that they want to make it publicly\n> available via git, or even just have backups). It's also encouraged\n> by sites like github, where you might clone the upstream's\n> repository, but then pushes your changes up to a personal \"fork\"\n> to let others see and merge them.\n> \n> So I think part of the reason we don't have such an option is that cases\n> 1-3 are so common. But it would be a nice convenience for people in case\n> 4.\n\nI think github is making option 4 the dominant use case. In fact, in our workplace we have a similar workflow set up, where we pull from a central origin, but push to individual mirrors from where commits are reviewed, tested, and merged unto origin.\n\n--David"},{"id":"167486","messageId":"20110509111019.GD9060@sigill.intra.peff.net","threadId":"27290","inReplyTo":"D0FA0C3F-8DA8-4607-A0A6-F9AFAB3EC3CE@gmail.com","subject":"Re: Separate default remotes for pulling and pushing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-09T11:10:19Z","receivedAt":"2011-05-09T11:10:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 09, 2011 at 01:34:22AM -0700, David Lee wrote:\n\n> > 4. Decentralized, you're a developer that publishes work via git. You\n> > call the upstream maintainer \"origin\", so fetches are convenient\n> > (and git does this for you at clone, after all). But pushing, even\n> > though you probably always push to the same central, does not have\n> > a convenient shorthand.\n> \n> By \"push to the same central\", I assume you mean \"push to the same mirror of origin\".\n\nYeah, sorry, that was supposed to be \"central spot\", but I think you got\nthe meaning.\n\n> I think github is making option 4 the dominant use case. In fact, in\n> our workplace we have a similar workflow set up, where we pull from a\n> central origin, but push to individual mirrors from where commits are\n> reviewed, tested, and merged unto origin.\n\nYeah, I think we will see more of that as decentralized workflows (and\nthe tools that support them) mature.\n\nWith respect to supporting an alternate default push destination, I'm\nnot sure what is the best change to make. If \"origin\" were simply the\ndefault, I would say we should have a push.defaultRemote config that\nlets you specify something else.\n\nBut it's not that simple. If you are on branch \"foo\", and you have\n\"branch.foo.remote\" set in your config, then the value of that config\noption becomes the default remote. Which makes some sense for pulling\n(and there is the associated branch.*.merge config), but of course\npushing may not match.\n\nBut now we have precedence questions. If I have config like:\n\n [push]\n defaultRemote = my-mirror\n\n [branch \"foo\"]\n remote = origin\n merge = refs/heads/master\n\nwhich remote should be the default for \"git push\"? Obviously if I'm not\non \"foo\", it should be my-mirror. But if I am, should push.defaultRemote\ntake precedence? Should there also be a branch.*.pushRemote config that\ntakes precedence over branch.*.remote?\n\nI have to admit that I have never found the branch.*.remote config to be\nuseful for any of my workflows, so I am not really sure how people use\nit.\n\n-Peff\n"},{"id":"167511","messageId":"7viptjq0ua.fsf@alter.siamese.dyndns.org","threadId":"27290","inReplyTo":"20110509081708.GA5871@sigill.intra.peff.net","subject":"Re: Separate default remotes for pulling and pushing","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-09T16:45:49Z","receivedAt":"2011-05-09T16:45:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> 4. Decentralized, you're a developer that publishes work via git. You\n> call the upstream maintainer \"origin\", so fetches are convenient\n> (and git does this for you at clone, after all). But pushing, even\n> though you probably always push to the same central, does not have\n> a convenient shorthand.\n>\n> This is David's case (and mine, and I suspect some other git\n> developers who do enough work that they want to make it publicly\n> available via git, or even just have backups). It's also encouraged\n> by sites like github, where you might clone the upstream's\n> repository, but then pushes your changes up to a personal \"fork\"\n> to let others see and merge them.\n\nIn a sense, this is what I do as well. As you mentioned, I push to \"ko\"\nto publish, but when I \"fetch\" (or \"pull\") from \"origin\", I get the public\ncopy I have at kernel.org like everybody else, and I do fetch every time\nafter I push to \"ko\" to get the updated preformatted HTML and man page\nbranches.\n\nI never felt it awkward that my fetch says \"origin\" and my push says \"ko\".\nEven though I imagine that I could smash them together into a single\n\"origin\", it would not give me anything, as I also push to push to\ndifferent places like repo.or.cz, sourceforge and github anyway.\n\nWhile I see why some people might want to say \"origin\" for both in such a\nset-up (when they do not push to multiple places like I do), I have a\nfeeling that it is a misguided wish that would make themselves unnecessary\nconfused than they already are, especially if the repositories used for\npushing and fetching are in reality different repositories (one good\nexample why it would be confusing is how remote tracking branches are\nupdated).\n"},{"id":"167515","messageId":"53DAF1E7-9906-4BF4-A64B-FE16BF5977F5@gmail.com","threadId":"27290","inReplyTo":"20110509111019.GD9060@sigill.intra.peff.net","subject":"Re: Separate default remotes for pulling and pushing","fromName":"David Lee","fromEmail":"davidomundo@gmail.com","sentAt":"2011-05-09T19:01:53Z","receivedAt":"2011-05-09T19:01:53Z","isPatch":false,"sender":{"key":"davidomundo@gmail.com","avatar":null},"body":"\n> But now we have precedence questions. If I have config like:\n> \n> [push]\n> defaultRemote = my-mirror\n> \n> [branch \"foo\"]\n> remote = origin\n> merge = refs/heads/master\n> \n> which remote should be the default for \"git push\"? Obviously if I'm not\n> on \"foo\", it should be my-mirror. But if I am, should push.defaultRemote\n> take precedence? Should there also be a branch.*.pushRemote config that\n> takes precedence over branch.*.remote?\n> \n> I have to admit that I have never found the branch.*.remote config to be\n> useful for any of my workflows, so I am not really sure how people use\n> it.\n\nWhat about removing the branch.*.remote config by default, and if it's not set, then it defaults to whatever the repo-wide setting is for defaultRemote? Then a branch.*.remote would override the defaultRemote, and a branch.*.pushRemote would again override that."},{"id":"167535","messageId":"20110509220459.GA3719@sigill.intra.peff.net","threadId":"27290","inReplyTo":"7viptjq0ua.fsf@alter.siamese.dyndns.org","subject":"Re: Separate default remotes for pulling and pushing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-09T22:04:59Z","receivedAt":"2011-05-09T22:04:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 09, 2011 at 09:45:49AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > 4. Decentralized, you're a developer that publishes work via git. You\n> > call the upstream maintainer \"origin\", so fetches are convenient\n> > (and git does this for you at clone, after all). But pushing, even\n> > though you probably always push to the same central, does not have\n> > a convenient shorthand.\n> >\n> > This is David's case (and mine, and I suspect some other git\n> > developers who do enough work that they want to make it publicly\n> > available via git, or even just have backups). It's also encouraged\n> > by sites like github, where you might clone the upstream's\n> > repository, but then pushes your changes up to a personal \"fork\"\n> > to let others see and merge them.\n> \n> In a sense, this is what I do as well. As you mentioned, I push to \"ko\"\n> to publish, but when I \"fetch\" (or \"pull\") from \"origin\", I get the public\n> copy I have at kernel.org like everybody else, and I do fetch every time\n> after I push to \"ko\" to get the updated preformatted HTML and man page\n> branches.\n\nInteresting. Is your fetch from \"ko\" a no-op, or are you using it to\nsyncrhonize development between different machines?\n\n> While I see why some people might want to say \"origin\" for both in such a\n> set-up (when they do not push to multiple places like I do), I have a\n> feeling that it is a misguided wish that would make themselves unnecessary\n> confused than they already are, especially if the repositories used for\n> pushing and fetching are in reality different repositories (one good\n> example why it would be confusing is how remote tracking branches are\n> updated).\n\nI think it is important to note that calling them both \"origin\" is\ndefinitely the wrong thing. The proposal is instead that \"git push\"\nwithout a remote would default to something besides \"origin\". For people\nwho publish multiple places, it might even make sense for it to be an\niterative push to each place.\n\nBut this is all definitely a minor convenience. It is not that\nworld-shattering to type \"git push my-fork\", nor \"git push my-fork &&\ngit push my-backup\". Probably twice a week I accidentally try to push to\n\"git://git.kernel.org/pub/scm/git/git.git\", but git make it clear that\nis not allowed. :)\n\n-Peff\n"},{"id":"167536","messageId":"20110509220638.GB3719@sigill.intra.peff.net","threadId":"27290","inReplyTo":"53DAF1E7-9906-4BF4-A64B-FE16BF5977F5@gmail.com","subject":"Re: Separate default remotes for pulling and pushing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-09T22:06:38Z","receivedAt":"2011-05-09T22:06:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 09, 2011 at 12:01:53PM -0700, David Lee wrote:\n\n> > But now we have precedence questions. If I have config like:\n> > \n> > [push]\n> > defaultRemote = my-mirror\n> > \n> > [branch \"foo\"]\n> > remote = origin\n> > merge = refs/heads/master\n> > \n> > which remote should be the default for \"git push\"? Obviously if I'm not\n> > on \"foo\", it should be my-mirror. But if I am, should push.defaultRemote\n> > take precedence? Should there also be a branch.*.pushRemote config that\n> > takes precedence over branch.*.remote?\n> > \n> > I have to admit that I have never found the branch.*.remote config to be\n> > useful for any of my workflows, so I am not really sure how people use\n> > it.\n> \n> What about removing the branch.*.remote config by default, and if it's\n> not set, then it defaults to whatever the repo-wide setting is for\n> defaultRemote? Then a branch.*.remote would override the\n> defaultRemote, and a branch.*.pushRemote would again override that.\n\nThe branch.*.remote config does much more, though. For example, it is\npart of the \"upstream\" branch config. So getting rid of it is definitely\nnot an option.\n\n-Peff\n"},{"id":"167545","messageId":"7vaaevo5l0.fsf@alter.siamese.dyndns.org","threadId":"27290","inReplyTo":"20110509220459.GA3719@sigill.intra.peff.net","subject":"Re: Separate default remotes for pulling and pushing","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-09T22:46:19Z","receivedAt":"2011-05-09T22:46:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> In a sense, this is what I do as well. As you mentioned, I push to \"ko\"\n>> to publish, but when I \"fetch\" (or \"pull\") from \"origin\", I get the public\n>> copy I have at kernel.org like everybody else, and I do fetch every time\n>> after I push to \"ko\" to get the updated preformatted HTML and man page\n>> branches.\n>\n> Interesting. Is your fetch from \"ko\" a no-op, or are you using it to\n> syncrhonize development between different machines?\n\nPreformatted html and man pages are made when I push the integrated source\nbranches out, triggered from the post-update hook at kernel.org. I do not\nformat them on my box.\n\nI say \"git push ko\", take a sip of tea, and after k.org finishes the\nasciidoc dance \"git fetch ko\" to get them all, before pushing\nremotes/ko/{maint,master,next,pu,todo,html,man} to secondary sites.\n\n> I think it is important to note that calling them both \"origin\" is\n> definitely the wrong thing. The proposal is instead that \"git push\"\n> without a remote would default to something besides \"origin\". For people\n> who publish multiple places, it might even make sense for it to be an\n> iterative push to each place.\n\nEither we add branch..pushremote or push.defaultremote then?\n"},{"id":"167596","messageId":"BANLkTimUn9e=5CfDcvQdgNYY4_pqbi8peQ@mail.gmail.com","threadId":"27290","inReplyTo":"20110509220459.GA3719@sigill.intra.peff.net","subject":"Re: Separate default remotes for pulling and pushing","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-05-10T12:47:53Z","receivedAt":"2011-05-10T12:47:53Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, May 9, 2011 at 6:04 PM, Jeff King wrote:\n> I think it is important to note that calling them both \"origin\" is\n> definitely the wrong thing. The proposal is instead that \"git push\"\n> without a remote would default to something besides \"origin\". For people\n> who publish multiple places, it might even make sense for it to be an\n> iterative push to each place.\n\nWhile developing in a particular repo, I constantly have to push to\ntwo compile machines. I just dropped a Makefile into the top of my\nworking tree:\n\nall: push\namend:\n\tgit amend -a\n\tgit --no-pager diff @{1}\n\tmake push\npush:\n\tmake -j 2 mac win\nmac:\n\tgit push mac\nwin:\n\tgit push win\n\nj.\n"},{"id":"167621","messageId":"20110510201716.GE14456@sigill.intra.peff.net","threadId":"27290","inReplyTo":"7vaaevo5l0.fsf@alter.siamese.dyndns.org","subject":"Re: Separate default remotes for pulling and pushing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-10T20:17:16Z","receivedAt":"2011-05-10T20:17:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 09, 2011 at 03:46:19PM -0700, Junio C Hamano wrote:\n\n> > Interesting. Is your fetch from \"ko\" a no-op, or are you using it to\n> > syncrhonize development between different machines?\n> \n> Preformatted html and man pages are made when I push the integrated source\n> branches out, triggered from the post-update hook at kernel.org. I do not\n> format them on my box.\n\nAh, that makes sense.\n\n> > I think it is important to note that calling them both \"origin\" is\n> > definitely the wrong thing. The proposal is instead that \"git push\"\n> > without a remote would default to something besides \"origin\". For people\n> > who publish multiple places, it might even make sense for it to be an\n> > iterative push to each place.\n> \n> Either we add branch..pushremote or push.defaultremote then?\n\nI don't think most people would want just branch..pushremote. They\nare more likely to want to always push to some place, so\npush.defaultremote is a better choice.\n\nBut that has weird precedence problems. We auto-create branch.*.remote,\nso if branch-specific config takes precedence, their push.defaultremote\nwill almost never be used. And if branch-specific config _doesn't_ take\nprecedence, then that is weird and unlike almost every other part of\ngit.\n\nAnother option is to mark the remote with an explicit \"don't push here,\npush to this other remote instead\" config, like:\n\n $ git remote add my-fork host:project.git\n $ git config remote.origin.pushremote my-fork\n $ git push ;# acts as if you did \"git push my-fork\"\n\nAnd then when we default to a remote, either because it is \"origin\" or\nbecause it is in branch.*.remote, then we will end up pushing to the\nright place.\n\nI'm unsure what should happen in the case of:\n\n $ git config remote.origin.pushremote my-fork\n $ git push origin\n\nIn the workflow we described, \"origin\" is simply not a push-able remote,\nso it is a slight convenience to intercept all pushes for it and\ntransparently rewrite them to \"my-fork\". And it makes the concept of\nthat config slightly simpler. It basically becomes the equivalent of\nremote.*.pushurl, except that we are clear that it is a totally separate\nremote with different tracking branches.\n\nBut it does eliminate any workflow where \"origin\" is _sometimes_\npushable, but you almost always want to push somewhere else instead.\nBecause you have no way to push to \"origin\" now. I don't know of any\nsuch workflow, but I hate to be restrictive for no good reason.\n\nIf it just handles \"use this remote instead only in the case of a\ndefault selection\", then the name should probably be like\n\"defaultpushremote\" or something.\n\n-Peff\n"},{"id":"167622","messageId":"20110510202003.GF14456@sigill.intra.peff.net","threadId":"27290","inReplyTo":"BANLkTimUn9e=5CfDcvQdgNYY4_pqbi8peQ@mail.gmail.com","subject":"Re: Separate default remotes for pulling and pushing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-10T20:20:03Z","receivedAt":"2011-05-10T20:20:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 10, 2011 at 08:47:53AM -0400, Jay Soffian wrote:\n\n> On Mon, May 9, 2011 at 6:04 PM, Jeff King wrote:\n> > I think it is important to note that calling them both \"origin\" is\n> > definitely the wrong thing. The proposal is instead that \"git push\"\n> > without a remote would default to something besides \"origin\". For people\n> > who publish multiple places, it might even make sense for it to be an\n> > iterative push to each place.\n> \n> While developing in a particular repo, I constantly have to push to\n> two compile machines. I just dropped a Makefile into the top of my\n> working tree:\n> \n> all: push\n> amend:\n> \tgit amend -a\n> \tgit --no-pager diff @{1}\n> \tmake push\n> push:\n> \tmake -j 2 mac win\n> mac:\n> \tgit push mac\n> win:\n> \tgit push win\n\nYeah, I have scripts to help with that sort of thing now. But that is\noften an unsatisfactory solution, because either:\n\n 1. Your Makefile is not version-controlled.\n\n 2. Your are polluting the project history with stuff specific to your\n workflow. I would not get very far proposing that git.git's\n Makefile contain such a thing. :)\n\nThat's how Junio ended up with his \"Meta\" directory (and I have one,\ntoo, but with drastically different things in it).\n\n-Peff\n"},{"id":"167631","messageId":"BANLkTi=V23wUiyQavaCVBJ_vA+gnL9m00w@mail.gmail.com","threadId":"27290","inReplyTo":"20110510202003.GF14456@sigill.intra.peff.net","subject":"Re: Separate default remotes for pulling and pushing","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-05-10T21:12:57Z","receivedAt":"2011-05-10T21:12:57Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, May 10, 2011 at 4:20 PM, Jeff King wrote:\n> Yeah, I have scripts to help with that sort of thing now. But that is\n> often an unsatisfactory solution, because either:\n>\n>  1. Your Makefile is not version-controlled.\n\nSure, but your .git/config is similarly not version controlled.\n\n>\n>  2. Your are polluting the project history with stuff specific to your\n>     workflow. I would not get very far proposing that git.git's\n>     Makefile contain such a thing. :)\n>\n> That's how Junio ended up with his \"Meta\" directory (and I have one,\n> too, but with drastically different things in it).\n\nAs well. :-)\n\nj.\n"}]}