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@xxxxxxxx> --- 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
