Using push.default with push.remote.push

Using push.default with push.remote.push

[Robert Dailey]

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.

Re: Using push.default with push.remote.push

[Robert Dailey]

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`.

Re: Using push.default with push.remote.push

[Jeff King]

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

Re: Using push.default with push.remote.push

[Robert Dailey]

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".

Re: Using push.default with push.remote.push

[Robert Dailey]

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.

Re: Using push.default with push.remote.push

[Jeff King]

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