From: Bert Wesarg Date: Mon, 27 Jan 2020 07:00:22 GMT Subject: Re: [PATCH] doc: clarify "explicitly given" in push.default Message-ID: In-Reply-To: <20200125200554.GC5519@coredump.intra.peff.net> 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 > --- > 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