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@xxxxxxxxxxxxxxxxxxxxxxx/ 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
