From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
Ramkumar Ramachandra <artagnon@gmail.com>,
Git List <git@vger.kernel.org>,
Matthieu Moy <matthieu.moy@imag.fr>,
John Szakmeister <john@szakmeister.net>
Subject: Re: [PATCH v2 6/9] branch: display publish branch
Date: Fri, 11 Apr 2014 14:50:38 -0500 [thread overview]
Message-ID: <5348478e1bc46_2c1f6e72ecbb@nysa.notmuch> (raw)
In-Reply-To: <xmqqsipjsm8c.fsf@gitster.dls.corp.google.com>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > For instance, it looks like your @{publish} requires config like:
> >
> > [branch "master"]
> > pushremote = foo
> > push = refs/heads/bar
> >
> > to operate. Setting "pushremote" affects what "git push" does; it will
> > go to the "foo" remote.
>
> OK, and the same thing would happen if branch.*.pushremote is not
> set for any branch, but remote.pushdefault is set to 'foo', right?
>
> > But the branch.master.push setting does not do
> > anything to "git push".
>
> I am not sure I understand this. I thought that the desire behind
> the branch.*.push is to allow something like:
>
> ... other things in the config ...
> [remote]
> pushdefault = foo
> [remote "foo"]
> url = ...
> push = +refs/heads/*:refs/remotes/satellite/*
> fetch = +refs/heads/*:refs/remotes/foo/*
> [branch "master"]
> ; pushremote = foo
> push = refs/heads/bar
>
> so that "git push" on 'master' will override the more generic "all
> local branches here will go to their remote-tracking hierarchy for
> this satellite" refspec. And in that sense branch.master.push would
> do something to "git push".
In my patches the above doesn't work; branch.master.push doesn't do anything if
.pushremote isn't there.
I'm always thinking from the common user's point of view, and the common user
doesn't know what branch.master.push is, but he knows he did
`git branch -p foo/bar master` (or something like that), and
`git branch -v` would corroborate that.
So you would have something like this:
[remote "foo"]
url = ...
push = +refs/heads/*:refs/remotes/satellite/*
fetch = +refs/heads/*:refs/remotes/foo/*
[branch "master"]
pushremote = foo
push = refs/heads/bar
> I personally think that kind of override adds any more values than
> it causes confusion, so I think it is OK not to support such uses of
> branch.*.push at all. A configuration without branch.master.push
> may cause "git push" on 'master' to update refs/heads/master at the
> remote,
How? If branch.master.push is not configured, then "git push" would push
'master' to refs/remotes/satellite/master on the remote.
--
Felipe Contreras
next prev parent reply other threads:[~2014-04-11 20:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-10 19:04 [PATCH v2 0/9] Introduce publish tracking branch Felipe Contreras
2014-04-10 19:04 ` [PATCH v2 1/9] push: trivial reorganization Felipe Contreras
2014-04-10 19:04 ` [PATCH v2 2/9] Add concept of 'publish' branch Felipe Contreras
2014-04-10 19:04 ` [PATCH v2 3/9] branch: allow configuring the publish branch Felipe Contreras
2014-04-10 19:04 ` [PATCH v2 4/9] t: branch add publish branch tests Felipe Contreras
2014-04-10 19:04 ` [PATCH v2 5/9] push: add --set-publish option Felipe Contreras
2014-04-10 19:04 ` [PATCH v2 6/9] branch: display publish branch Felipe Contreras
2014-04-10 22:03 ` Ramkumar Ramachandra
2014-04-10 22:36 ` Felipe Contreras
2014-04-11 11:17 ` Jeff King
2014-04-11 13:48 ` Felipe Contreras
2014-04-12 11:23 ` Jeff King
2014-04-12 14:34 ` Felipe Contreras
2014-04-11 19:24 ` Junio C Hamano
2014-04-11 19:50 ` Felipe Contreras [this message]
2014-04-12 11:42 ` Jeff King
2014-04-12 15:05 ` Felipe Contreras
2014-04-15 5:43 ` Jeff King
2014-04-18 23:29 ` Felipe Contreras
2014-04-10 19:04 ` [PATCH v2 7/9] sha1_name: cleanup interpret_branch_name() Felipe Contreras
2014-04-10 21:45 ` Ramkumar Ramachandra
2014-04-10 19:04 ` [PATCH v2 8/9] sha1_name: simplify track finding Felipe Contreras
2014-04-10 21:44 ` Ramkumar Ramachandra
2014-04-10 22:27 ` Felipe Contreras
2014-04-10 19:04 ` [PATCH v2 9/9] sha1_name: add support for @{publish} marks Felipe Contreras
2014-04-10 21:40 ` Ramkumar Ramachandra
2014-04-10 22:25 ` Felipe Contreras
2014-04-10 21:49 ` Ramkumar Ramachandra
2014-04-10 22:28 ` Felipe Contreras
2014-04-10 21:21 ` [PATCH v2 0/9] Introduce publish tracking branch Junio C Hamano
2014-04-11 9:15 ` Matthieu Moy
2014-04-11 14:25 ` Felipe Contreras
2014-04-11 17:25 ` Matthieu Moy
2014-04-11 19:16 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5348478e1bc46_2c1f6e72ecbb@nysa.notmuch \
--to=felipe.contreras@gmail.com \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=john@szakmeister.net \
--cc=matthieu.moy@imag.fr \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).