* Using push.default with push.remote.push @ 2020-03-11 15:41 Robert Dailey 2020-03-11 15:43 ` Robert Dailey 2020-03-11 16:25 ` Jeff King 0 siblings, 2 replies; 6+ messages in thread From: Robert Dailey @ 2020-03-11 15:41 UTC (permalink / raw) To: Git 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.<remote>.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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Using push.default with push.remote.push 2020-03-11 15:41 Using push.default with push.remote.push Robert Dailey @ 2020-03-11 15:43 ` Robert Dailey 2020-03-11 16:25 ` Jeff King 1 sibling, 0 replies; 6+ messages in thread From: Robert Dailey @ 2020-03-11 15:43 UTC (permalink / raw) To: Git On Wed, Mar 11, 2020 at 10:41 AM Robert Dailey <rcdailey.lists@gmail.com> 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.<remote>.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.<remote>.push` above should have been `remote.<remote>.push`. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Using push.default with push.remote.push 2020-03-11 15:41 Using push.default with push.remote.push Robert Dailey 2020-03-11 15:43 ` Robert Dailey @ 2020-03-11 16:25 ` Jeff King 2020-03-11 16:56 ` Robert Dailey 1 sibling, 1 reply; 6+ messages in thread From: Jeff King @ 2020-03-11 16:25 UTC (permalink / raw) To: Robert Dailey; +Cc: Git 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.<remote>.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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Using push.default with push.remote.push 2020-03-11 16:25 ` Jeff King @ 2020-03-11 16:56 ` Robert Dailey 2020-03-11 17:01 ` Robert Dailey 2020-03-11 19:10 ` Jeff King 0 siblings, 2 replies; 6+ messages in thread From: Robert Dailey @ 2020-03-11 16:56 UTC (permalink / raw) To: Jeff King; +Cc: Git On Wed, Mar 11, 2020 at 11:25 AM Jeff King <peff@peff.net> 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.<remote>.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". ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Using push.default with push.remote.push 2020-03-11 16:56 ` Robert Dailey @ 2020-03-11 17:01 ` Robert Dailey 2020-03-11 19:10 ` Jeff King 1 sibling, 0 replies; 6+ messages in thread From: Robert Dailey @ 2020-03-11 17:01 UTC (permalink / raw) To: Jeff King; +Cc: Git On Wed, Mar 11, 2020 at 11:56 AM Robert Dailey <rcdailey.lists@gmail.com> wrote: > > On Wed, Mar 11, 2020 at 11:25 AM Jeff King <peff@peff.net> 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.<remote>.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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Using push.default with push.remote.push 2020-03-11 16:56 ` Robert Dailey 2020-03-11 17:01 ` Robert Dailey @ 2020-03-11 19:10 ` Jeff King 1 sibling, 0 replies; 6+ messages in thread From: Jeff King @ 2020-03-11 19:10 UTC (permalink / raw) To: Robert Dailey; +Cc: Git 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-03-11 19:10 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-11 15:41 Using push.default with push.remote.push Robert Dailey 2020-03-11 15:43 ` Robert Dailey 2020-03-11 16:25 ` Jeff King 2020-03-11 16:56 ` Robert Dailey 2020-03-11 17:01 ` Robert Dailey 2020-03-11 19:10 ` Jeff King
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.