* 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
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).