# Re: Using push.default with push.remote.push 6 messages from 2020-03-11 to 2020-03-11. Participants: Robert Dailey, Jeff King. Thread: https://gitlist.dev/t/52977 ## Robert Dailey, 2020-03-11 15:41 Subject: Using push.default with push.remote.push Message-ID: URL: https://gitlist.dev/e/CAHd499BhLe0xF_k2ASV%3DZuM7LVvxui_cxzB9UrJ2MDCyyNUmtw%40mail.gmail.com ``` With the specified configuration: ˋˋˋ [push] default = current [remote "origin"] url = git@mydomain:myrepo fetch = +refs/heads/dev/john/*:refs/remotes/origin/* fetch = +refs/heads/*:refs/remotes/origin/* push = refs/heads/master:refs/heads/master push = refs/heads/*:refs/heads/dev/john/* ˋˋˋ Given a currently checked out local branch named `my-feature`, how can I make this command: git push -n origin Behave semantically identical to this command? git push -n origin my-feature The current behavior seems to be working as designed, but not as desired. The first push command pushes *all* branches under `refs/heads/*`, instead of just the current branch as it normally would via `push.default` setting. It sort of feels like if a resolved, explicitly defined `push..push` config is found *and* it includes wildcards, the `push.default` setting should still be respected. Are there any workarounds to getting the behavior I'm looking for? Note my ultimate goal here is to transparently map local branches to a branch with a prefix on the remote. But I do not want to explicitly work with or see those prefixes locally. Basically `dev/john/my-feature` on the remote should be `refs/heads/my-feature` locally, and `refs/remotes/origin/my-feature` for fetches. The push-without-explicit-refspec case is the only one I haven't gotten to work as desired yet. ``` ## Robert Dailey, 2020-03-11 15:43 Subject: Re: Using push.default with push.remote.push Message-ID: URL: https://gitlist.dev/e/CAHd499DcLsffD6RHK2x-k3JWk4BtR-NLx_WnAYesz9d%2Bw_m8AQ%40mail.gmail.com In-Reply-To: ``` On Wed, Mar 11, 2020 at 10:41 AM Robert Dailey wrote: > > With the specified configuration: > > ˋˋˋ > [push] > default = current > [remote "origin"] > url = git@mydomain:myrepo > fetch = +refs/heads/dev/john/*:refs/remotes/origin/* > fetch = +refs/heads/*:refs/remotes/origin/* > push = refs/heads/master:refs/heads/master > push = refs/heads/*:refs/heads/dev/john/* > ˋˋˋ > > Given a currently checked out local branch named `my-feature`, how can > I make this command: > > git push -n origin > > Behave semantically identical to this command? > > git push -n origin my-feature > > The current behavior seems to be working as designed, but not as > desired. The first push command pushes *all* branches under > `refs/heads/*`, instead of just the current branch as it normally > would via `push.default` setting. It sort of feels like if a resolved, > explicitly defined `push..push` config is found *and* it > includes wildcards, the `push.default` setting should still be > respected. > > Are there any workarounds to getting the behavior I'm looking for? > > Note my ultimate goal here is to transparently map local branches to a > branch with a prefix on the remote. But I do not want to explicitly > work with or see those prefixes locally. Basically > `dev/john/my-feature` on the remote should be `refs/heads/my-feature` > locally, and `refs/remotes/origin/my-feature` for fetches. The > push-without-explicit-refspec case is the only one I haven't gotten to > work as desired yet. Correction: `push..push` above should have been `remote..push`. ``` ## Jeff King, 2020-03-11 16:25 Subject: Re: Using push.default with push.remote.push Message-ID: <20200311162517.GA27893@coredump.intra.peff.net> URL: https://gitlist.dev/e/20200311162517.GA27893%40coredump.intra.peff.net In-Reply-To: ``` On Wed, Mar 11, 2020 at 10:41:36AM -0500, Robert Dailey wrote: > With the specified configuration: > > ˋˋˋ > [push] > default = current > [remote "origin"] > url = git@mydomain:myrepo > fetch = +refs/heads/dev/john/*:refs/remotes/origin/* > fetch = +refs/heads/*:refs/remotes/origin/* > push = refs/heads/master:refs/heads/master > push = refs/heads/*:refs/heads/dev/john/* > ˋˋˋ > > Given a currently checked out local branch named `my-feature`, how can > I make this command: > > git push -n origin > > Behave semantically identical to this command? > > git push -n origin my-feature I don't know of a way. If we had branch.*.pushRef (and not just pushRemote), it would presumably do what you want. This came up recently in: https://lore.kernel.org/git/20200127231459.GD19360@coredump.intra.peff.net/ as well. > The current behavior seems to be working as designed, but not as > desired. The first push command pushes *all* branches under > `refs/heads/*`, instead of just the current branch as it normally > would via `push.default` setting. It sort of feels like if a resolved, > explicitly defined `push..push` config is found *and* it > includes wildcards, the `push.default` setting should still be > respected. Then when would remote.*.push with a wildcard ever do anything? > Note my ultimate goal here is to transparently map local branches to a > branch with a prefix on the remote. But I do not want to explicitly > work with or see those prefixes locally. Basically > `dev/john/my-feature` on the remote should be `refs/heads/my-feature` > locally, and `refs/remotes/origin/my-feature` for fetches. The > push-without-explicit-refspec case is the only one I haven't gotten to > work as desired yet. I think this is similar to what was desired in the thread I linked above. -Peff ``` ## Robert Dailey, 2020-03-11 16:56 Subject: Re: Using push.default with push.remote.push Message-ID: URL: https://gitlist.dev/e/CAHd499AGQ5k7ON%2BYY84b6LY1sh9MOw8fsrE2shOibujX1iKeiQ%40mail.gmail.com In-Reply-To: <20200311162517.GA27893@coredump.intra.peff.net> ``` On Wed, Mar 11, 2020 at 11:25 AM Jeff King wrote: > > The current behavior seems to be working as designed, but not as > > desired. The first push command pushes *all* branches under > > `refs/heads/*`, instead of just the current branch as it normally > > would via `push.default` setting. It sort of feels like if a resolved, > > explicitly defined `push..push` config is found *and* it > > includes wildcards, the `push.default` setting should still be > > respected. > > Then when would remote.*.push with a wildcard ever do anything? Maybe this is where a potential disconnect is, but I've always viewed the wildcard refspec as a mapping, rather than an all-inclusive "Push all the things". In other words, I view it as more of a structural guide than a behavioral one. I recognize I probably have this wrong, but it probably speaks to how some users view it, or at least, some valid use cases to have more of a structural mechanism to map branches to remote repositories, with `git push --all` being a supplement to say "Push all branches using this mapping". ``` ## Robert Dailey, 2020-03-11 17:01 Subject: Re: Using push.default with push.remote.push Message-ID: URL: https://gitlist.dev/e/CAHd499Dbqa9jZ0bLTiayy%2BS6c1si1wOYddA1SDUz22g-Jp-TQg%40mail.gmail.com In-Reply-To: ``` On Wed, Mar 11, 2020 at 11:56 AM Robert Dailey wrote: > > On Wed, Mar 11, 2020 at 11:25 AM Jeff King wrote: > > > The current behavior seems to be working as designed, but not as > > > desired. The first push command pushes *all* branches under > > > `refs/heads/*`, instead of just the current branch as it normally > > > would via `push.default` setting. It sort of feels like if a resolved, > > > explicitly defined `push..push` config is found *and* it > > > includes wildcards, the `push.default` setting should still be > > > respected. > > > > Then when would remote.*.push with a wildcard ever do anything? > > Maybe this is where a potential disconnect is, but I've always viewed > the wildcard refspec as a mapping, rather than an all-inclusive "Push > all the things". In other words, I view it as more of a structural > guide than a behavioral one. I recognize I probably have this wrong, > but it probably speaks to how some users view it, or at least, some > valid use cases to have more of a structural mechanism to map branches > to remote repositories, with `git push --all` being a supplement to > say "Push all branches using this mapping". Also, apologies, I forgot to include a response to your first reply to my OP: I think `branch.*.pushRef` in this case is not enough. It implies that for every branch I want to be mapped in this way, I'd have to manually specify this config. Rather, I think a `remote.*.pushRef` would be more appropriate, so that it would automatically set the `branch.*.pushRef` version as needed, so I only set up the mapping once. It could also be I don't fully understand your recommendation, so apologies of that's the case. ``` ## Jeff King, 2020-03-11 19:10 Subject: Re: Using push.default with push.remote.push Message-ID: <20200311191021.GA27978@coredump.intra.peff.net> URL: https://gitlist.dev/e/20200311191021.GA27978%40coredump.intra.peff.net In-Reply-To: ``` On Wed, Mar 11, 2020 at 11:56:05AM -0500, Robert Dailey wrote: > > Then when would remote.*.push with a wildcard ever do anything? > > Maybe this is where a potential disconnect is, but I've always viewed > the wildcard refspec as a mapping, rather than an all-inclusive "Push > all the things". In other words, I view it as more of a structural > guide than a behavioral one. I recognize I probably have this wrong, > but it probably speaks to how some users view it, or at least, some > valid use cases to have more of a structural mechanism to map branches > to remote repositories, with `git push --all` being a supplement to > say "Push all branches using this mapping". I see. So you really want "push the current branch by default, but using this refspec to map the names". That doesn't exist right now, but it seems like it would be a reasonable thing to have. Bringing in your other reply: > I think `branch.*.pushRef` in this case is not enough. It implies that > for every branch I want to be mapped in this way, I'd have to manually > specify this config. Rather, I think a `remote.*.pushRef` would be > more appropriate, so that it would automatically set the > `branch.*.pushRef` version as needed, so I only set up the mapping > once. Yes, my suggestion would require per-branch config. And something like remote.*.pushRef makes sense to me as the implementation for what we were discussing above. I think you'd want the name to somehow indicate that it's a mapping to be used when pushing a ref, and not the definitive "this is what we will push" directive. I don't think it would make sense to use with something like "upstream" in push.default, because that's mapping the name already. So possibly it should be restricted to "current". I suppose it would also make sense with "matching". There the current remote.*.push _mostly_ does the same thing, but with one subtle exception that it pushes everything that matches the left-hand side of the refspec, not just ones that exist on the right-hand side. So I dunno. I could see it as being limited to "current", or being applied as it makes sense for each individual push.default. I'll leave that to whoever decides to work on the feature. :) -Peff ```