threads / discuss / 52977

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

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

## tl;dr

6 messages between Mar 11, 2020 and Mar 11, 2020.

replies: 5people: 2as markdown or json

Robert Dailey· Mar 11, 2020, 15:41 UTC · lore

Using push.default with push.remote.push

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.

Robert Dailey· Mar 11, 2020, 15:43 UTC · re: Robert Dailey · lore
On Wed, Mar 11, 2020 at 10:41 AM Robert Dailey <rcdailey.lists@gmail.com> wrote:
Show 40 quoted lines
>
> 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`.
Jeff King· Mar 11, 2020, 16:25 UTC · re: Robert Dailey · lore
On Wed, Mar 11, 2020 at 10:41:36AM -0500, Robert Dailey wrote:
Show 21 quoted lines
> 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.
Show 7 quoted lines
> 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?
Show 7 quoted lines
> 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· Mar 11, 2020, 16:56 UTC · re: Jeff King · lore
On Wed, Mar 11, 2020 at 11:25 AM Jeff King <peff@peff.net> wrote:
Show 9 quoted lines
> > 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".

Robert Dailey· Mar 11, 2020, 17:01 UTC · re: Robert Dailey · lore
On Wed, Mar 11, 2020 at 11:56 AM Robert Dailey <rcdailey.lists@gmail.com> wrote:
Show 20 quoted lines
>
> 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.

Jeff King· Mar 11, 2020, 19:10 UTC · re: Robert Dailey · lore
On Wed, Mar 11, 2020 at 11:56:05AM -0500, Robert Dailey wrote:
Show 10 quoted lines
> > 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:
Show 6 quoted lines
> 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

← back to recent threads