# push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote 3 messages from 2013-09-10 to 2013-09-11. Participants: Ximin Luo, Junio C Hamano, Felipe Contreras. Thread: https://gitlist.dev/t/34896 ## Ximin Luo, 2013-09-10 13:10 Subject: push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote Message-ID: <522F1A61.3010805@gmx.com> URL: https://gitlist.dev/e/522F1A61.3010805%40gmx.com ``` (Please CC me as I am not subscribed.) $ git config -l | grep '^branch.master\|^push.' push.default=upstream branch.master.remote=upstream branch.master.merge=refs/heads/master branch.master.pushremote=origin $ git branch * master $ git push fatal: You are pushing to remote 'origin', which is not the upstream of your current branch 'master', without telling me what to push to update which remote branch. push.default=upstream means "push back where it came from (*)". However, if I specifically define remote.pushdefault or branch.*.pushremote, this clearly means I don't want to do (*) in this case. The question here then is, what remote branch should git push to - since pushremote only specifies a repo? I can suggest two options: - A: push to branch.*.merge if it's defined; otherwise push to (like push.default=current) - B: push to regardless B is probably simpler and means you can amend the push.default manual entry more easily: upstream: [..] This mode only makes sense if you are pushing to the same repository you would normally pull from (i.e. central workflow). If you are not pushing to the same repository, acts as "current". (Note again; that this is a special case when push.default=upstream because of the "this mode only makes sense" semantics. The other values for push.default are simpler and do not result in a conflict.) Alternatively, an even more simple behaviour is to adjust the error message to communicate the root cause: $ git push fatal: branch.*.pushremote is not compatible with push.default = upstream X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git ``` ## Junio C Hamano, 2013-09-10 16:06 Subject: Re: push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote Message-ID: URL: https://gitlist.dev/e/xmqqsixczmnu.fsf%40gitster.dls.corp.google.com In-Reply-To: <522F1A61.3010805@gmx.com> ``` Ximin Luo writes: > (Please CC me as I am not subscribed.) > > $ git config -l | grep '^branch.master\|^push.' > push.default=upstream > branch.master.remote=upstream > branch.master.merge=refs/heads/master > branch.master.pushremote=origin > > $ git branch > * master > > $ git push > fatal: You are pushing to remote 'origin', which is not the upstream of > your current branch 'master', without telling me what to push > to update which remote branch. > > push.default=upstream means "push back where it came from (*)". However, if I specifically define remote.pushdefault or branch.*.pushremote, this clearly means I don't want to do (*) in this case. I think this was discussed on the list during the last development cycle. Please check the list archive. "git config --help" has this to say about it: * `upstream` - push the current branch back to the branch whose changes are usually integrated into the current branch (which is called `@{upstream}`). This mode only makes sense if you are pushing to the same repository you would normally pull from (i.e. central workflow). * `simple` - in centralized workflow, work like `upstream` with an added safety to refuse to push if the upstream branch's name is different from the local one. When pushing to a remote that is different from the remote you normally pull from, work as `current`. ``` ## Felipe Contreras, 2013-09-11 00:38 Subject: Re: push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote Message-ID: URL: https://gitlist.dev/e/CAMP44s0ZnGAhMv0a4HbVkZ6voRzxrXW-4T6Dj%3DH3Lb3kGFsOHA%40mail.gmail.com In-Reply-To: <522F1A61.3010805@gmx.com> ``` On Tue, Sep 10, 2013 at 8:10 AM, Ximin Luo wrote: > (Please CC me as I am not subscribed.) No need to say that, Git mailing list is sane and doesn't do reply-to munging. > The question here then is, what remote branch should git push to - since pushremote only specifies a repo? I can suggest two options: > > - A: push to branch.*.merge if it's defined; otherwise push to (like push.default=current) > - B: push to regardless Or C: introduce the concept of a publish branch to complement pushremote: http://article.gmane.org/gmane.comp.version-control.git/233572 -- Felipe Contreras ```