* push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote
@ 2013-09-10 13:10 Ximin Luo
2013-09-10 16:06 ` Junio C Hamano
2013-09-11 0:38 ` Felipe Contreras
0 siblings, 2 replies; 3+ messages in thread
From: Ximin Luo @ 2013-09-10 13:10 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]
(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 <current branch> (like push.default=current)
- B: push to <current branch> 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). <INS>If you are not pushing to the same repository, acts as "current".</INS>
(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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote
2013-09-10 13:10 push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote Ximin Luo
@ 2013-09-10 16:06 ` Junio C Hamano
2013-09-11 0:38 ` Felipe Contreras
1 sibling, 0 replies; 3+ messages in thread
From: Junio C Hamano @ 2013-09-10 16:06 UTC (permalink / raw)
To: Ximin Luo; +Cc: git
Ximin Luo <infinity0@gmx.com> 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`.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote
2013-09-10 13:10 push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote Ximin Luo
2013-09-10 16:06 ` Junio C Hamano
@ 2013-09-11 0:38 ` Felipe Contreras
1 sibling, 0 replies; 3+ messages in thread
From: Felipe Contreras @ 2013-09-11 0:38 UTC (permalink / raw)
To: Ximin Luo; +Cc: git
On Tue, Sep 10, 2013 at 8:10 AM, Ximin Luo <infinity0@gmx.com> 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 <current branch> (like push.default=current)
> - B: push to <current branch> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-09-11 0:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-10 13:10 push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote Ximin Luo
2013-09-10 16:06 ` Junio C Hamano
2013-09-11 0:38 ` Felipe Contreras
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.