On Wed, Mar 11, 2020 at 10:41 AM Robert Dailey <rcdailey.lists@xxxxxxxxx> 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`.
