* [Q] push refspec with wildcard pushes all matching branches
@ 2020-01-24 20:29 Bert Wesarg
2020-01-25 0:38 ` Jeff King
0 siblings, 1 reply; 16+ messages in thread
From: Bert Wesarg @ 2020-01-24 20:29 UTC (permalink / raw)
To: git
Dear all,
I'm a little confused, that a push refspec with a wildcard changes the number of branches pushed.
Here is what I see with Git 2.25:
$ git --version
git version 2.25.0
$ git config --list
user.email=bert.wesarg@googlemail.com
user.name=Bert Wesarg
$ git init --bare bare.git
$ git clone bare.git repo
Cloning into 'repo'...
warning: You appear to have cloned an empty repository.
done.
$ cd repo
$ git config push.default current
$ echo foo >foo
$ git add foo
$ git commit -m foo
[master (root-commit) 4d0b276] foo
1 file changed, 1 insertion(+)
create mode 100644 foo
$ git branch master-two
$ git push --dry-run
To ../bare.git
* [new branch] master -> master
$ git config remote.origin.push 'refs/heads/master*:refs/remotes/origin/master*'
$ git push --dry-run
To ../bare.git
* [new branch] master -> origin/master
* [new branch] master-two -> origin/master-two
Is this expected behavior?
Thanks.
Best,
Bert
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Q] push refspec with wildcard pushes all matching branches 2020-01-24 20:29 [Q] push refspec with wildcard pushes all matching branches Bert Wesarg @ 2020-01-25 0:38 ` Jeff King 2020-01-25 7:38 ` Bert Wesarg 0 siblings, 1 reply; 16+ messages in thread From: Jeff King @ 2020-01-25 0:38 UTC (permalink / raw) To: Bert Wesarg; +Cc: git On Fri, Jan 24, 2020 at 09:29:53PM +0100, Bert Wesarg wrote: > I'm a little confused, that a push refspec with a wildcard changes the number of branches pushed. I'm confused about which part you're confused about. :) > $ git push --dry-run > To ../bare.git > * [new branch] master -> master > $ git config remote.origin.push 'refs/heads/master*:refs/remotes/origin/master*' > $ git push --dry-run > To ../bare.git > * [new branch] master -> origin/master > * [new branch] master-two -> origin/master-two > > Is this expected behavior? You asked it to push master*, so it did. Is your confusion that you had set push.default to "current"? If there is a refspec (either in the config or specified on the command line), then that takes precedence over push.default. From git-push(1): When the command line does not specify what to push with <refspec>... arguments or --all, --mirror, --tags options, the command finds the default <refspec> by consulting remote.*.push configuration, and if it is not found, honors push.default configuration to decide what to push (See git-config(1) for the meaning of push.default). If that's not it, can you clarify what you expected to happen? -Peff ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Q] push refspec with wildcard pushes all matching branches 2020-01-25 0:38 ` Jeff King @ 2020-01-25 7:38 ` Bert Wesarg 2020-01-25 20:05 ` [PATCH] doc: clarify "explicitly given" in push.default Jeff King 0 siblings, 1 reply; 16+ messages in thread From: Bert Wesarg @ 2020-01-25 7:38 UTC (permalink / raw) To: Jeff King; +Cc: git On 25.01.20 01:38, Jeff King wrote: > On Fri, Jan 24, 2020 at 09:29:53PM +0100, Bert Wesarg wrote: > >> I'm a little confused, that a push refspec with a wildcard changes the number of branches pushed. > > I'm confused about which part you're confused about. :) > >> $ git push --dry-run >> To ../bare.git >> * [new branch] master -> master >> $ git config remote.origin.push 'refs/heads/master*:refs/remotes/origin/master*' >> $ git push --dry-run >> To ../bare.git >> * [new branch] master -> origin/master >> * [new branch] master-two -> origin/master-two >> >> Is this expected behavior? > > You asked it to push master*, so it did. > > Is your confusion that you had set push.default to "current"? If there > is a refspec (either in the config or specified on the command line), > then that takes precedence over push.default. > > From git-push(1): > > When the command line does not specify what to push with <refspec>... > arguments or --all, --mirror, --tags options, the command finds the > default <refspec> by consulting remote.*.push configuration, and if it > is not found, honors push.default configuration to decide what to push > (See git-config(1) for the meaning of push.default). > > If that's not it, can you clarify what you expected to happen? thanks for this pointer. My initial pointer was the help for push.default: From git-config(1): push.default Defines the action git push should take if no refspec is explicitly given. Different values are well-suited for specific workflows; for Thus I expected, that this takes effect, when just calling 'git push'. What I actually want to achieve, is to track a remote branch with a different name locally, but 'git push' should nevertheless push to tracked remote branch. In my example above, befor adding the 'push.origin.push' refspec, rename the branch: $ git branch -m local $ git push --dry-run To ../bare.git * [new branch] local -> local Is it possible that this pushes to the tracked branch automatically, and because I have multiple such branches, without the use of a push refspec. Thanks for the help. Best, Bert > > -Peff > ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH] doc: clarify "explicitly given" in push.default 2020-01-25 7:38 ` Bert Wesarg @ 2020-01-25 20:05 ` Jeff King 2020-01-27 7:00 ` Bert Wesarg 0 siblings, 1 reply; 16+ messages in thread From: Jeff King @ 2020-01-25 20:05 UTC (permalink / raw) To: Bert Wesarg; +Cc: git On Sat, Jan 25, 2020 at 08:38:04AM +0100, Bert Wesarg wrote: > thanks for this pointer. My initial pointer was the help for push.default: > > From git-config(1): > > push.default > Defines the action git push should take if no refspec is explicitly > given. Different values are well-suited for specific workflows; for > > Thus I expected, that this takes effect, when just calling 'git push'. Yeah, I agree "explicitly given" is vague there. Perhaps the patch below is worth doing? > What I actually want to achieve, is to track a remote branch with a > different name locally, but 'git push' should nevertheless push to > tracked remote branch. > > In my example above, befor adding the 'push.origin.push' refspec, rename the branch: > > $ git branch -m local > $ git push --dry-run > To ../bare.git > * [new branch] local -> local > > Is it possible that this pushes to the tracked branch automatically, > and because I have multiple such branches, without the use of a push > refspec. I think if push.default is set to "upstream" then it would do what you want as long as you set the upstream of "local" (e.g., by doing "git branch --set-upstream-to=origin/master local). There's another way of doing this, which is when you have a "triangular" flow: you might pull changes from origin/master into your local branch X, but then push them elsewhere. Usually this would be pushing to a branch named X on a different remote than origin (e.g., your public fork of upstream on a server). And for that you can set branch.X.pushRemote. There's no corresponding triangular config branch.X.pushBranch to push to a different name than "X" on the remote. And while I do think it would be rare to want it, I could imagine a case (you have a triangular flow where everybody shares a central repo, but you want to push to some local namespace within it; usually people do that now by just making the namespace part of their local branch names, too). Anyway, here's the documentation patch. -- >8 -- Subject: [PATCH] doc: clarify "explicitly given" in push.default The documentation for push.default mentions that it is used if no refspec is "explicitly given". Let's clarify that giving a refspec on the command-line _or_ in the config will override it. Signed-off-by: Jeff King <peff@peff.net> --- Documentation/config/push.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt index 0a0e000569..554ab44b4c 100644 --- a/Documentation/config/push.txt +++ b/Documentation/config/push.txt @@ -1,6 +1,7 @@ push.default:: Defines the action `git push` should take if no refspec is - explicitly given. Different values are well-suited for + explicitly given (either on the command-line or via a + `remote.*.push` config option). Different values are well-suited for specific workflows; for instance, in a purely central workflow (i.e. the fetch source is equal to the push destination), `upstream` is probably what you want. Possible values are: -- 2.25.0.430.g8dfc7de6f7 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH] doc: clarify "explicitly given" in push.default 2020-01-25 20:05 ` [PATCH] doc: clarify "explicitly given" in push.default Jeff King @ 2020-01-27 7:00 ` Bert Wesarg 2020-01-27 7:02 ` Jeff King 2020-01-27 19:48 ` Bert Wesarg 0 siblings, 2 replies; 16+ messages in thread From: Bert Wesarg @ 2020-01-27 7:00 UTC (permalink / raw) To: Jeff King; +Cc: git On 25.01.20 21:05, Jeff King wrote: > On Sat, Jan 25, 2020 at 08:38:04AM +0100, Bert Wesarg wrote: > >> thanks for this pointer. My initial pointer was the help for push.default: >> >> From git-config(1): >> >> push.default >> Defines the action git push should take if no refspec is explicitly >> given. Different values are well-suited for specific workflows; for >> >> Thus I expected, that this takes effect, when just calling 'git push'. > > Yeah, I agree "explicitly given" is vague there. Perhaps the patch below > is worth doing? > >> What I actually want to achieve, is to track a remote branch with a >> different name locally, but 'git push' should nevertheless push to >> tracked remote branch. >> >> In my example above, befor adding the 'push.origin.push' refspec, rename the branch: >> >> $ git branch -m local >> $ git push --dry-run >> To ../bare.git >> * [new branch] local -> local >> >> Is it possible that this pushes to the tracked branch automatically, >> and because I have multiple such branches, without the use of a push >> refspec. > > I think if push.default is set to "upstream" then it would do what you > want as long as you set the upstream of "local" (e.g., by doing "git > branch --set-upstream-to=origin/master local). Thanks. This pushes only the current branch and honors the 'rename'. > > There's another way of doing this, which is when you have a "triangular" > flow: you might pull changes from origin/master into your local branch > X, but then push them elsewhere. Usually this would be pushing to a > branch named X on a different remote than origin (e.g., your public fork > of upstream on a server). And for that you can set branch.X.pushRemote. > > There's no corresponding triangular config branch.X.pushBranch to push > to a different name than "X" on the remote. And while I do think it > would be rare to want it, I could imagine a case (you have a triangular > flow where everybody shares a central repo, but you want to push to some > local namespace within it; usually people do that now by just making the > namespace part of their local branch names, too). > > Anyway, here's the documentation patch. > > -- >8 -- > Subject: [PATCH] doc: clarify "explicitly given" in push.default > > The documentation for push.default mentions that it is used if no > refspec is "explicitly given". Let's clarify that giving a refspec on > the command-line _or_ in the config will override it. > > Signed-off-by: Jeff King <peff@peff.net> > --- > Documentation/config/push.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt > index 0a0e000569..554ab44b4c 100644 > --- a/Documentation/config/push.txt > +++ b/Documentation/config/push.txt > @@ -1,6 +1,7 @@ > push.default:: > Defines the action `git push` should take if no refspec is > - explicitly given. Different values are well-suited for > + explicitly given (either on the command-line or via a > + `remote.*.push` config option). Different values are well-suited for > specific workflows; for instance, in a purely central workflow > `upstream` is probably what you want. Possible values are: > I would rather talk about 'implicitly given', if it is via a `remote.*.push` config option: Defines the action `git push` should take if no refspec is - explicitly given. Different values are well-suited for - specific workflows; for instance, in a purely central workflow - (i.e. the fetch source is equal to the push destination), - `upstream` is probably what you want. Possible values are: + neither explicitly (on the command-line) nor implicitly (via a + `remote.*.push` config option) given. Different values are + well-suited for specific workflows; for instance, in a purely + central workflow (i.e. the fetch source is equal to the push + destination), `upstream` is probably what you want. Possible + values are: Bert ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] doc: clarify "explicitly given" in push.default 2020-01-27 7:00 ` Bert Wesarg @ 2020-01-27 7:02 ` Jeff King 2020-01-27 9:25 ` Bert Wesarg 2020-01-27 19:48 ` Bert Wesarg 1 sibling, 1 reply; 16+ messages in thread From: Jeff King @ 2020-01-27 7:02 UTC (permalink / raw) To: Bert Wesarg; +Cc: git On Mon, Jan 27, 2020 at 08:00:22AM +0100, Bert Wesarg wrote: > > diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt > > index 0a0e000569..554ab44b4c 100644 > > --- a/Documentation/config/push.txt > > +++ b/Documentation/config/push.txt > > @@ -1,6 +1,7 @@ > > push.default:: > > Defines the action `git push` should take if no refspec is > > - explicitly given. Different values are well-suited for > > + explicitly given (either on the command-line or via a > > + `remote.*.push` config option). Different values are well-suited for > > specific workflows; for instance, in a purely central workflow > > `upstream` is probably what you want. Possible values are: > > > > I would rather talk about 'implicitly given', if it is via a `remote.*.push` config option: > > Defines the action `git push` should take if no refspec is > - explicitly given. Different values are well-suited for > - specific workflows; for instance, in a purely central workflow > - (i.e. the fetch source is equal to the push destination), > - `upstream` is probably what you want. Possible values are: > + neither explicitly (on the command-line) nor implicitly (via a > + `remote.*.push` config option) given. Different values are > + well-suited for specific workflows; for instance, in a purely > + central workflow (i.e. the fetch source is equal to the push > + destination), `upstream` is probably what you want. Possible > + values are: Yeah, that sounds fine. Want to wrap it up with as a patch with a commit message? -Peff ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH] doc: clarify "explicitly given" in push.default 2020-01-27 7:02 ` Jeff King @ 2020-01-27 9:25 ` Bert Wesarg 2020-01-27 23:12 ` Jeff King 2020-01-28 22:11 ` Junio C Hamano 0 siblings, 2 replies; 16+ messages in thread From: Bert Wesarg @ 2020-01-27 9:25 UTC (permalink / raw) To: git; +Cc: Bert Wesarg, Jeff King The documentation for push.default mentions that it is used if no refspec is "explicitly given". Let's clarify that giving a refspec on the command-line _or_ in the config will override it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> --- Documentation/config/push.txt | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) Cc: peff@peff.net diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt index 0a0e000569..d560362c9a 100644 --- a/Documentation/config/push.txt +++ b/Documentation/config/push.txt @@ -1,9 +1,11 @@ push.default:: Defines the action `git push` should take if no refspec is - explicitly given. Different values are well-suited for - specific workflows; for instance, in a purely central workflow - (i.e. the fetch source is equal to the push destination), - `upstream` is probably what you want. Possible values are: + neither explicitly (on the command-line) nor implicitly (via a + `remote.*.push` config option) given. Different values are + well-suited for specific workflows; for instance, in a purely + central workflow (i.e. the fetch source is equal to the push + destination), `upstream` is probably what you want. Possible + values are: + -- -- 2.24.1.497.g9abd7b20b4.dirty ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH] doc: clarify "explicitly given" in push.default 2020-01-27 9:25 ` Bert Wesarg @ 2020-01-27 23:12 ` Jeff King 2020-01-28 22:11 ` Junio C Hamano 1 sibling, 0 replies; 16+ messages in thread From: Jeff King @ 2020-01-27 23:12 UTC (permalink / raw) To: Bert Wesarg; +Cc: git On Mon, Jan 27, 2020 at 10:25:03AM +0100, Bert Wesarg wrote: > The documentation for push.default mentions that it is used if no > refspec is "explicitly given". Let's clarify that giving a refspec on > the command-line _or_ in the config will override it. Yep, looks good to me. > Signed-off-by: Jeff King <peff@peff.net> > Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> I don't know that we need my S-o-b anymore. The content in this one is all you. :) (But certainly I don't mind endorsing it). -Peff ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] doc: clarify "explicitly given" in push.default 2020-01-27 9:25 ` Bert Wesarg 2020-01-27 23:12 ` Jeff King @ 2020-01-28 22:11 ` Junio C Hamano 2020-01-29 2:41 ` Jeff King 1 sibling, 1 reply; 16+ messages in thread From: Junio C Hamano @ 2020-01-28 22:11 UTC (permalink / raw) To: Bert Wesarg; +Cc: git, Jeff King Bert Wesarg <bert.wesarg@googlemail.com> writes: > The documentation for push.default mentions that it is used if no > refspec is "explicitly given". Let's clarify that giving a refspec on > the command-line _or_ in the config will override it. > > Signed-off-by: Jeff King <peff@peff.net> > Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> > --- > Documentation/config/push.txt | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > Cc: peff@peff.net > > diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt > index 0a0e000569..d560362c9a 100644 > --- a/Documentation/config/push.txt > +++ b/Documentation/config/push.txt > @@ -1,9 +1,11 @@ > push.default:: > Defines the action `git push` should take if no refspec is > - explicitly given. Different values are well-suited for > - specific workflows; for instance, in a purely central workflow > - (i.e. the fetch source is equal to the push destination), > - `upstream` is probably what you want. Possible values are: > + neither explicitly (on the command-line) nor implicitly (via a > + `remote.*.push` config option) given. Different values are > + well-suited for specific workflows; for instance, in a purely > + central workflow (i.e. the fetch source is equal to the push > + destination), `upstream` is probably what you want. Possible > + values are: > + > -- Hmph, I am not sure the act of deliberately setting remote.*.push configuration should not count as an explicit request to Git the user makes. Immediately follows the above, the description of one of the possible values read thusly: * `nothing` - do not push anything (error out) unless a refspec is explicitly given. This is primarily meant for people who want to avoid mistakes by always being explicit. which may need an adjustment to keep the whole coherent. If we decide to say that setting configuration does not count as explicit, then "unless a refspec is explicitly given" should be updated to match. There may be other mention of "explicitly" that needs to be adjusted (I didn't hunt for it, but the above one was adjacent and I couldn't not see it). If we have to change anything in the description, I would say that we can just drop "explicitly". There are ways to give refspec from the command line, remote.*.push configuration, in .git/remotes file, etc. If it were "if you give refspec from command line, X happens, but giving a config-sourced refspec does not cause X to happen", that may be a good reason to invent and use a new phrase "implicitly given" that is not used in this paragraph. But push.default kicks in only when *none* of these ways is used to give *any* refspec, so there is not much point differenciating between the command line sourced refspec and config sourced refspec in the context of discussing this feature, I would think. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] doc: clarify "explicitly given" in push.default 2020-01-28 22:11 ` Junio C Hamano @ 2020-01-29 2:41 ` Jeff King 2020-01-29 5:21 ` Junio C Hamano 0 siblings, 1 reply; 16+ messages in thread From: Jeff King @ 2020-01-29 2:41 UTC (permalink / raw) To: Junio C Hamano; +Cc: Bert Wesarg, git On Tue, Jan 28, 2020 at 02:11:01PM -0800, Junio C Hamano wrote: > > push.default:: > > Defines the action `git push` should take if no refspec is > > - explicitly given. Different values are well-suited for > > - specific workflows; for instance, in a purely central workflow > > - (i.e. the fetch source is equal to the push destination), > > - `upstream` is probably what you want. Possible values are: > > + neither explicitly (on the command-line) nor implicitly (via a > > + `remote.*.push` config option) given. Different values are > > + well-suited for specific workflows; for instance, in a purely > > + central workflow (i.e. the fetch source is equal to the push > > + destination), `upstream` is probably what you want. Possible > > + values are: > > + > > -- > > Hmph, I am not sure the act of deliberately setting remote.*.push > configuration should not count as an explicit request to Git the > user makes. > > Immediately follows the above, the description of one of the > possible values read thusly: > > * `nothing` - do not push anything (error out) unless a refspec is > explicitly given. This is primarily meant for people who want to > avoid mistakes by always being explicit. > > which may need an adjustment to keep the whole coherent. Yeah, you're right. The term "explicit" gets thrown around a fair bit there. In that sense my original was slightly better, in that it defines "explicit" (one might say it even does so...explicitly). But... > If we have to change anything in the description, I would say that > we can just drop "explicitly". [...] Yes, I like dropping that word even better. Though I'd still slightly worry that somebody might not consider configured refspecs. Saying more clearly "any refspec no matter where it comes from" might still be worthwhile. I.e., something like: Defines the action `git push` should take if no refspec is given (whether from the command-line, config, or elsewhere). ? -Peff ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] doc: clarify "explicitly given" in push.default 2020-01-29 2:41 ` Jeff King @ 2020-01-29 5:21 ` Junio C Hamano 2020-01-29 5:53 ` Jeff King 0 siblings, 1 reply; 16+ messages in thread From: Junio C Hamano @ 2020-01-29 5:21 UTC (permalink / raw) To: Jeff King; +Cc: Bert Wesarg, git Jeff King <peff@peff.net> writes: > Though I'd still slightly worry that somebody might not consider > configured refspecs. Saying more clearly "any refspec no matter where it > comes from" might still be worthwhile. I.e., something like: > > Defines the action `git push` should take if no refspec is given > (whether from the command-line, config, or elsewhere). That's 100x better than to say "explicit" "implicit" etc. and then have readers guess what the adjectives mean or explain what they mean in (parentheses). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] doc: clarify "explicitly given" in push.default 2020-01-29 5:21 ` Junio C Hamano @ 2020-01-29 5:53 ` Jeff King 0 siblings, 0 replies; 16+ messages in thread From: Jeff King @ 2020-01-29 5:53 UTC (permalink / raw) To: Junio C Hamano; +Cc: Bert Wesarg, git On Tue, Jan 28, 2020 at 09:21:32PM -0800, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > > Though I'd still slightly worry that somebody might not consider > > configured refspecs. Saying more clearly "any refspec no matter where it > > comes from" might still be worthwhile. I.e., something like: > > > > Defines the action `git push` should take if no refspec is given > > (whether from the command-line, config, or elsewhere). > > That's 100x better than to say "explicit" "implicit" etc. and then > have readers guess what the adjectives mean or explain what they > mean in (parentheses). OK, here it is in patch form, then, so we can (hopefully) wrap this up. -- >8 -- Subject: [PATCH] doc: drop "explicitly given" from push.default description The documentation for push.default mentions that it is used if no refspec is "explicitly given". Let's drop the notion of "explicit" here, since it's vague, and just mention that any refspec from anywhere is sufficient to override this. I've dropped the mention of "explicitly given" frmo the definition of the "nothing" value right below, too. It's close enough to our clarification that it should be obvious we mean the same type of "given" here. Signed-off-by: Jeff King <peff@peff.net> --- Note that there's one other use of the word "explicit" in the context, but it is used appropriately. :) Documentation/config/push.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt index 0a0e000569..54871f8213 100644 --- a/Documentation/config/push.txt +++ b/Documentation/config/push.txt @@ -1,14 +1,15 @@ push.default:: Defines the action `git push` should take if no refspec is - explicitly given. Different values are well-suited for + given (whether from the command-line, config, or elsewhere). + Different values are well-suited for specific workflows; for instance, in a purely central workflow (i.e. the fetch source is equal to the push destination), `upstream` is probably what you want. Possible values are: + -- * `nothing` - do not push anything (error out) unless a refspec is - explicitly given. This is primarily meant for people who want to + given. This is primarily meant for people who want to avoid mistakes by always being explicit. * `current` - push the current branch to update a branch with the same -- 2.25.0.515.g69a699b7aa ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH] doc: clarify "explicitly given" in push.default 2020-01-27 7:00 ` Bert Wesarg 2020-01-27 7:02 ` Jeff King @ 2020-01-27 19:48 ` Bert Wesarg 2020-01-27 20:53 ` Bert Wesarg 2020-01-27 23:14 ` Jeff King 1 sibling, 2 replies; 16+ messages in thread From: Bert Wesarg @ 2020-01-27 19:48 UTC (permalink / raw) To: Jeff King; +Cc: git Dear Jeff, On 27.01.20 08:00, Bert Wesarg wrote: > On 25.01.20 21:05, Jeff King wrote: >> On Sat, Jan 25, 2020 at 08:38:04AM +0100, Bert Wesarg wrote: >> >>> thanks for this pointer. My initial pointer was the help for push.default: >>> >>> From git-config(1): >>> >>> push.default >>> Defines the action git push should take if no refspec is explicitly >>> given. Different values are well-suited for specific workflows; for >>> >>> Thus I expected, that this takes effect, when just calling 'git push'. >> >> Yeah, I agree "explicitly given" is vague there. Perhaps the patch below >> is worth doing? >> >>> What I actually want to achieve, is to track a remote branch with a >>> different name locally, but 'git push' should nevertheless push to >>> tracked remote branch. >>> >>> In my example above, befor adding the 'push.origin.push' refspec, rename the branch: >>> >>> $ git branch -m local >>> $ git push --dry-run >>> To ../bare.git >>> * [new branch] local -> local >>> >>> Is it possible that this pushes to the tracked branch automatically, >>> and because I have multiple such branches, without the use of a push >>> refspec. >> >> I think if push.default is set to "upstream" then it would do what you >> want as long as you set the upstream of "local" (e.g., by doing "git >> branch --set-upstream-to=origin/master local). > > Thanks. This pushes only the current branch and honors the 'rename'. while this works … > >> >> There's another way of doing this, which is when you have a "triangular" >> flow: you might pull changes from origin/master into your local branch >> X, but then push them elsewhere. Usually this would be pushing to a >> branch named X on a different remote than origin (e.g., your public fork >> of upstream on a server). And for that you can set branch.X.pushRemote. … it does not play well if you have have both flows in one repository. And I do have both flows. I track the upstream 'master' in the local branch 'Y' and I have also a branch 'X' which is based on 'Y' but should be pushed to a different remote as branch 'Y'. I have configured 'branch.X.pushRemote = triangular' but with 'push.default' set to 'upstream' I get this when: $ git push triangular fatal: You are pushing to remote 'triangular', which is not the upstream of your current branch 'X', without telling me what to push to update which remote branch. In this simple case, without a renaming, I would expect that 'git push' just works. May be just fallback to 'simple' if 'upstream' does not resolve to a fully qualified push? Best, Bert ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] doc: clarify "explicitly given" in push.default 2020-01-27 19:48 ` Bert Wesarg @ 2020-01-27 20:53 ` Bert Wesarg 2020-01-27 23:14 ` Jeff King 1 sibling, 0 replies; 16+ messages in thread From: Bert Wesarg @ 2020-01-27 20:53 UTC (permalink / raw) To: Jeff King; +Cc: git On 27.01.20 20:48, Bert Wesarg wrote: > Dear Jeff, > > On 27.01.20 08:00, Bert Wesarg wrote: >> On 25.01.20 21:05, Jeff King wrote: >>> On Sat, Jan 25, 2020 at 08:38:04AM +0100, Bert Wesarg wrote: >>> >>>> thanks for this pointer. My initial pointer was the help for push.default: >>>> >>>> From git-config(1): >>>> >>>> push.default >>>> Defines the action git push should take if no refspec is explicitly >>>> given. Different values are well-suited for specific workflows; for >>>> >>>> Thus I expected, that this takes effect, when just calling 'git push'. >>> >>> Yeah, I agree "explicitly given" is vague there. Perhaps the patch below >>> is worth doing? >>> >>>> What I actually want to achieve, is to track a remote branch with a >>>> different name locally, but 'git push' should nevertheless push to >>>> tracked remote branch. >>>> >>>> In my example above, befor adding the 'push.origin.push' refspec, rename the branch: >>>> >>>> $ git branch -m local >>>> $ git push --dry-run >>>> To ../bare.git >>>> * [new branch] local -> local >>>> >>>> Is it possible that this pushes to the tracked branch automatically, >>>> and because I have multiple such branches, without the use of a push >>>> refspec. >>> >>> I think if push.default is set to "upstream" then it would do what you >>> want as long as you set the upstream of "local" (e.g., by doing "git >>> branch --set-upstream-to=origin/master local). >> >> Thanks. This pushes only the current branch and honors the 'rename'. > > while this works … > >> >>> >>> There's another way of doing this, which is when you have a "triangular" >>> flow: you might pull changes from origin/master into your local branch >>> X, but then push them elsewhere. Usually this would be pushing to a >>> branch named X on a different remote than origin (e.g., your public fork >>> of upstream on a server). And for that you can set branch.X.pushRemote. > > … it does not play well if you have have both flows in one repository. And I do have both flows. I track the upstream 'master' in the local branch 'Y' and I have also a branch 'X' which is based on 'Y' but should be pushed to a different remote as branch 'Y'. I have configured 'branch.X.pushRemote = triangular' but with 'push.default' set to 'upstream' I get this when: > > $ git push triangular > fatal: You are pushing to remote 'triangular', which is not the upstream of > your current branch 'X', without telling me what to push > to update which remote branch. > > In this simple case, without a renaming, I would expect that 'git push' just works. May be just fallback to 'simple' if 'upstream' does not resolve to a fully qualified push? Falling back to simple/current seems to work for my case: diff --git a/builtin/push.c b/builtin/push.c index 6dbf0f0bb7..6b2fac7977 100644 builtin/push.c --- a/builtin/push.c +++ b/builtin/push.c @@ -259,7 +259,10 @@ static void setup_default_push_refspecs(struct remote *remote) break; case PUSH_DEFAULT_UPSTREAM: - setup_push_upstream(remote, branch, triangular, 0); + if (triangular) + setup_push_current(remote, branch); + else + setup_push_upstream(remote, branch, triangular, 0); break; case PUSH_DEFAULT_CURRENT: It has some fallouts in the test suite, obviously. But is this something we should pursue at all? Bert ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH] doc: clarify "explicitly given" in push.default 2020-01-27 19:48 ` Bert Wesarg 2020-01-27 20:53 ` Bert Wesarg @ 2020-01-27 23:14 ` Jeff King 2020-01-28 20:48 ` Bert Wesarg 1 sibling, 1 reply; 16+ messages in thread From: Jeff King @ 2020-01-27 23:14 UTC (permalink / raw) To: Bert Wesarg; +Cc: git On Mon, Jan 27, 2020 at 08:48:01PM +0100, Bert Wesarg wrote: > > > There's another way of doing this, which is when you have a "triangular" > > > flow: you might pull changes from origin/master into your local branch > > > X, but then push them elsewhere. Usually this would be pushing to a > > > branch named X on a different remote than origin (e.g., your public fork > > > of upstream on a server). And for that you can set branch.X.pushRemote. > > … it does not play well if you have have both flows in one repository. > And I do have both flows. I track the upstream 'master' in the local > branch 'Y' and I have also a branch 'X' which is based on 'Y' but > should be pushed to a different remote as branch 'Y'. I have > configured 'branch.X.pushRemote = triangular' but with 'push.default' > set to 'upstream' I get this when: > > $ git push triangular > fatal: You are pushing to remote 'triangular', which is not the upstream of > your current branch 'X', without telling me what to push > to update which remote branch. > > In this simple case, without a renaming, I would expect that 'git > push' just works. May be just fallback to 'simple' if 'upstream' does > not resolve to a fully qualified push? I thought the point of "simple" was to be even more restrictive than "upstream". At any rate, your setup is sufficiently complicated that I think you'd be better off adding a branch.X.pushRef feature (essentially a refspec to be used just on branch X, though since the source side is implied, it's really just a destination ref). -Peff ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] doc: clarify "explicitly given" in push.default 2020-01-27 23:14 ` Jeff King @ 2020-01-28 20:48 ` Bert Wesarg 0 siblings, 0 replies; 16+ messages in thread From: Bert Wesarg @ 2020-01-28 20:48 UTC (permalink / raw) To: Jeff King; +Cc: Git Mailing List On Tue, Jan 28, 2020 at 12:15 AM Jeff King <peff@peff.net> wrote: > > On Mon, Jan 27, 2020 at 08:48:01PM +0100, Bert Wesarg wrote: > > > > > There's another way of doing this, which is when you have a "triangular" > > > > flow: you might pull changes from origin/master into your local branch > > > > X, but then push them elsewhere. Usually this would be pushing to a > > > > branch named X on a different remote than origin (e.g., your public fork > > > > of upstream on a server). And for that you can set branch.X.pushRemote. > > > > … it does not play well if you have have both flows in one repository. > > And I do have both flows. I track the upstream 'master' in the local > > branch 'Y' and I have also a branch 'X' which is based on 'Y' but > > should be pushed to a different remote as branch 'Y'. I have > > configured 'branch.X.pushRemote = triangular' but with 'push.default' > > set to 'upstream' I get this when: > > > > $ git push triangular > > fatal: You are pushing to remote 'triangular', which is not the upstream of > > your current branch 'X', without telling me what to push > > to update which remote branch. > > > > In this simple case, without a renaming, I would expect that 'git > > push' just works. May be just fallback to 'simple' if 'upstream' does > > not resolve to a fully qualified push? > > I thought the point of "simple" was to be even more restrictive than > "upstream". > > At any rate, your setup is sufficiently complicated that I think you'd > be better off adding a branch.X.pushRef feature (essentially a refspec > to be used just on branch X, though since the source side is implied, > it's really just a destination ref). thanks. I will try to come up with a patch. Bert > > -Peff ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-01-29 5:53 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-24 20:29 [Q] push refspec with wildcard pushes all matching branches Bert Wesarg 2020-01-25 0:38 ` Jeff King 2020-01-25 7:38 ` Bert Wesarg 2020-01-25 20:05 ` [PATCH] doc: clarify "explicitly given" in push.default Jeff King 2020-01-27 7:00 ` Bert Wesarg 2020-01-27 7:02 ` Jeff King 2020-01-27 9:25 ` Bert Wesarg 2020-01-27 23:12 ` Jeff King 2020-01-28 22:11 ` Junio C Hamano 2020-01-29 2:41 ` Jeff King 2020-01-29 5:21 ` Junio C Hamano 2020-01-29 5:53 ` Jeff King 2020-01-27 19:48 ` Bert Wesarg 2020-01-27 20:53 ` Bert Wesarg 2020-01-27 23:14 ` Jeff King 2020-01-28 20:48 ` Bert Wesarg
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 NNTP newsgroup(s).