{"thread":{"id":"52977","subject":"Re: Using push.default with push.remote.push","startedAt":"2020-03-11T15:42:01Z","lastAt":"2020-03-11T19:10:25Z","messageCount":6,"participants":["Robert Dailey","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"393083","messageId":"CAHd499BhLe0xF_k2ASV=ZuM7LVvxui_cxzB9UrJ2MDCyyNUmtw@mail.gmail.com","threadId":"52977","inReplyTo":null,"subject":"Using push.default with push.remote.push","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2020-03-11T15:41:36Z","receivedAt":"2020-03-11T15:42:01Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"With the specified configuration:\n\n```\n[push]\n default = current\n[remote \"origin\"]\n url = git@mydomain:myrepo\n fetch = +refs/heads/dev/john/*:refs/remotes/origin/*\n fetch = +refs/heads/*:refs/remotes/origin/*\n push = refs/heads/master:refs/heads/master\n push = refs/heads/*:refs/heads/dev/john/*\n```\n\nGiven a currently checked out local branch named `my-feature`, how can\nI make this command:\n\n git push -n origin\n\nBehave semantically identical to this command?\n\n git push -n origin my-feature\n\nThe current behavior seems to be working as designed, but not as\ndesired. The first push command pushes *all* branches under\n`refs/heads/*`, instead of just the current branch as it normally\nwould via `push.default` setting. It sort of feels like if a resolved,\nexplicitly defined `push..push` config is found *and* it\nincludes wildcards, the `push.default` setting should still be\nrespected.\n\nAre there any workarounds to getting the behavior I'm looking for?\n\nNote my ultimate goal here is to transparently map local branches to a\nbranch with a prefix on the remote. But I do not want to explicitly\nwork with or see those prefixes locally. Basically\n`dev/john/my-feature` on the remote should be `refs/heads/my-feature`\nlocally, and `refs/remotes/origin/my-feature` for fetches. The\npush-without-explicit-refspec case is the only one I haven't gotten to\nwork as desired yet.\n"},{"id":"393084","messageId":"CAHd499DcLsffD6RHK2x-k3JWk4BtR-NLx_WnAYesz9d+w_m8AQ@mail.gmail.com","threadId":"52977","inReplyTo":"CAHd499BhLe0xF_k2ASV=ZuM7LVvxui_cxzB9UrJ2MDCyyNUmtw@mail.gmail.com","subject":"Re: Using push.default with push.remote.push","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2020-03-11T15:43:14Z","receivedAt":"2020-03-11T15:43:31Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"On Wed, Mar 11, 2020 at 10:41 AM Robert Dailey wrote:\n>\n> With the specified configuration:\n>\n> ```\n> [push]\n> default = current\n> [remote \"origin\"]\n> url = git@mydomain:myrepo\n> fetch = +refs/heads/dev/john/*:refs/remotes/origin/*\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> push = refs/heads/master:refs/heads/master\n> push = refs/heads/*:refs/heads/dev/john/*\n> ```\n>\n> Given a currently checked out local branch named `my-feature`, how can\n> I make this command:\n>\n> git push -n origin\n>\n> Behave semantically identical to this command?\n>\n> git push -n origin my-feature\n>\n> The current behavior seems to be working as designed, but not as\n> desired. The first push command pushes *all* branches under\n> `refs/heads/*`, instead of just the current branch as it normally\n> would via `push.default` setting. It sort of feels like if a resolved,\n> explicitly defined `push..push` config is found *and* it\n> includes wildcards, the `push.default` setting should still be\n> respected.\n>\n> Are there any workarounds to getting the behavior I'm looking for?\n>\n> Note my ultimate goal here is to transparently map local branches to a\n> branch with a prefix on the remote. But I do not want to explicitly\n> work with or see those prefixes locally. Basically\n> `dev/john/my-feature` on the remote should be `refs/heads/my-feature`\n> locally, and `refs/remotes/origin/my-feature` for fetches. The\n> push-without-explicit-refspec case is the only one I haven't gotten to\n> work as desired yet.\n\nCorrection:\n\n`push..push` above should have been `remote..push`.\n"},{"id":"393074","messageId":"20200311162517.GA27893@coredump.intra.peff.net","threadId":"52977","inReplyTo":"CAHd499BhLe0xF_k2ASV=ZuM7LVvxui_cxzB9UrJ2MDCyyNUmtw@mail.gmail.com","subject":"Re: Using push.default with push.remote.push","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-03-11T16:25:17Z","receivedAt":"2020-03-11T16:26:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 11, 2020 at 10:41:36AM -0500, Robert Dailey wrote:\n\n> With the specified configuration:\n> \n> ```\n> [push]\n> default = current\n> [remote \"origin\"]\n> url = git@mydomain:myrepo\n> fetch = +refs/heads/dev/john/*:refs/remotes/origin/*\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> push = refs/heads/master:refs/heads/master\n> push = refs/heads/*:refs/heads/dev/john/*\n> ```\n> \n> Given a currently checked out local branch named `my-feature`, how can\n> I make this command:\n> \n> git push -n origin\n> \n> Behave semantically identical to this command?\n> \n> git push -n origin my-feature\n\nI don't know of a way. If we had branch.*.pushRef (and not just\npushRemote), it would presumably do what you want.\n\nThis came up recently in:\n\n https://lore.kernel.org/git/20200127231459.GD19360@coredump.intra.peff.net/\n\nas well.\n\n> The current behavior seems to be working as designed, but not as\n> desired. The first push command pushes *all* branches under\n> `refs/heads/*`, instead of just the current branch as it normally\n> would via `push.default` setting. It sort of feels like if a resolved,\n> explicitly defined `push..push` config is found *and* it\n> includes wildcards, the `push.default` setting should still be\n> respected.\n\nThen when would remote.*.push with a wildcard ever do anything?\n\n> Note my ultimate goal here is to transparently map local branches to a\n> branch with a prefix on the remote. But I do not want to explicitly\n> work with or see those prefixes locally. Basically\n> `dev/john/my-feature` on the remote should be `refs/heads/my-feature`\n> locally, and `refs/remotes/origin/my-feature` for fetches. The\n> push-without-explicit-refspec case is the only one I haven't gotten to\n> work as desired yet.\n\nI think this is similar to what was desired in the thread I linked\nabove.\n\n-Peff\n"},{"id":"393059","messageId":"CAHd499AGQ5k7ON+YY84b6LY1sh9MOw8fsrE2shOibujX1iKeiQ@mail.gmail.com","threadId":"52977","inReplyTo":"20200311162517.GA27893@coredump.intra.peff.net","subject":"Re: Using push.default with push.remote.push","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2020-03-11T16:56:05Z","receivedAt":"2020-03-11T16:56:20Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"On Wed, Mar 11, 2020 at 11:25 AM Jeff King wrote:\n> > The current behavior seems to be working as designed, but not as\n> > desired. The first push command pushes *all* branches under\n> > `refs/heads/*`, instead of just the current branch as it normally\n> > would via `push.default` setting. It sort of feels like if a resolved,\n> > explicitly defined `push..push` config is found *and* it\n> > includes wildcards, the `push.default` setting should still be\n> > respected.\n>\n> Then when would remote.*.push with a wildcard ever do anything?\n\nMaybe this is where a potential disconnect is, but I've always viewed\nthe wildcard refspec as a mapping, rather than an all-inclusive \"Push\nall the things\". In other words, I view it as more of a structural\nguide than a behavioral one. I recognize I probably have this wrong,\nbut it probably speaks to how some users view it, or at least, some\nvalid use cases to have more of a structural mechanism to map branches\nto remote repositories, with `git push --all` being a supplement to\nsay \"Push all branches using this mapping\".\n"},{"id":"393060","messageId":"CAHd499Dbqa9jZ0bLTiayy+S6c1si1wOYddA1SDUz22g-Jp-TQg@mail.gmail.com","threadId":"52977","inReplyTo":"CAHd499AGQ5k7ON+YY84b6LY1sh9MOw8fsrE2shOibujX1iKeiQ@mail.gmail.com","subject":"Re: Using push.default with push.remote.push","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2020-03-11T17:01:09Z","receivedAt":"2020-03-11T17:01:25Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"On Wed, Mar 11, 2020 at 11:56 AM Robert Dailey wrote:\n>\n> On Wed, Mar 11, 2020 at 11:25 AM Jeff King wrote:\n> > > The current behavior seems to be working as designed, but not as\n> > > desired. The first push command pushes *all* branches under\n> > > `refs/heads/*`, instead of just the current branch as it normally\n> > > would via `push.default` setting. It sort of feels like if a resolved,\n> > > explicitly defined `push..push` config is found *and* it\n> > > includes wildcards, the `push.default` setting should still be\n> > > respected.\n> >\n> > Then when would remote.*.push with a wildcard ever do anything?\n>\n> Maybe this is where a potential disconnect is, but I've always viewed\n> the wildcard refspec as a mapping, rather than an all-inclusive \"Push\n> all the things\". In other words, I view it as more of a structural\n> guide than a behavioral one. I recognize I probably have this wrong,\n> but it probably speaks to how some users view it, or at least, some\n> valid use cases to have more of a structural mechanism to map branches\n> to remote repositories, with `git push --all` being a supplement to\n> say \"Push all branches using this mapping\".\n\nAlso, apologies, I forgot to include a response to your first reply to my OP:\n\nI think `branch.*.pushRef` in this case is not enough. It implies that\nfor every branch I want to be mapped in this way, I'd have to manually\nspecify this config. Rather, I think a `remote.*.pushRef` would be\nmore appropriate, so that it would automatically set the\n`branch.*.pushRef` version as needed, so I only set up the mapping\nonce.\n\nIt could also be I don't fully understand your recommendation, so\napologies of that's the case.\n"},{"id":"393070","messageId":"20200311191021.GA27978@coredump.intra.peff.net","threadId":"52977","inReplyTo":"CAHd499AGQ5k7ON+YY84b6LY1sh9MOw8fsrE2shOibujX1iKeiQ@mail.gmail.com","subject":"Re: Using push.default with push.remote.push","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-03-11T19:10:21Z","receivedAt":"2020-03-11T19:10:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 11, 2020 at 11:56:05AM -0500, Robert Dailey wrote:\n\n> > Then when would remote.*.push with a wildcard ever do anything?\n> \n> Maybe this is where a potential disconnect is, but I've always viewed\n> the wildcard refspec as a mapping, rather than an all-inclusive \"Push\n> all the things\". In other words, I view it as more of a structural\n> guide than a behavioral one. I recognize I probably have this wrong,\n> but it probably speaks to how some users view it, or at least, some\n> valid use cases to have more of a structural mechanism to map branches\n> to remote repositories, with `git push --all` being a supplement to\n> say \"Push all branches using this mapping\".\n\nI see. So you really want \"push the current branch by default, but using\nthis refspec to map the names\". That doesn't exist right now, but it\nseems like it would be a reasonable thing to have.\n\nBringing in your other reply:\n\n> I think `branch.*.pushRef` in this case is not enough. It implies that\n> for every branch I want to be mapped in this way, I'd have to manually\n> specify this config. Rather, I think a `remote.*.pushRef` would be\n> more appropriate, so that it would automatically set the\n> `branch.*.pushRef` version as needed, so I only set up the mapping\n> once.\n\nYes, my suggestion would require per-branch config. And something like\nremote.*.pushRef makes sense to me as the implementation for what we\nwere discussing above. I think you'd want the name to somehow indicate\nthat it's a mapping to be used when pushing a ref, and not the\ndefinitive \"this is what we will push\" directive.\n\nI don't think it would make sense to use with something like \"upstream\"\nin push.default, because that's mapping the name already. So possibly it\nshould be restricted to \"current\". I suppose it would also make sense\nwith \"matching\". There the current remote.*.push _mostly_ does the same\nthing, but with one subtle exception that it pushes everything that\nmatches the left-hand side of the refspec, not just ones that exist on\nthe right-hand side.\n\nSo I dunno. I could see it as being limited to \"current\", or being\napplied as it makes sense for each individual push.default. I'll leave\nthat to whoever decides to work on the feature. :)\n\n-Peff\n"}]}