git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: 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 07:17:51 -0400	[thread overview]
Message-ID: <20140411111750.GA28858@sigill.intra.peff.net> (raw)
In-Reply-To: <53471d0b4c8dc_d696b12f08c@nysa.notmuch>

On Thu, Apr 10, 2014 at 05:36:59PM -0500, Felipe Contreras wrote:

> > I noticed that this only picks up a publish-branch if
> > branch.*.pushremote is configured. What happened to the case when
> > remote.pushdefault is configured?
> 
> What happens when branch.*.remote is not configured for @{upstream}? The same
> thing.

I don't know if that is a good comparison.

In other threads, the discussed meaning of @{publish} was something like
"the tracking branch of the ref you would push to if you ran 'git push'
without arguments".

That is consistent with @{upstream} being "the tracking branch of the
ref you would pull from with 'git pull'". But "git pull" without a
branch.*.remote will do nothing, so "what pull would do" is the same as
"what you have configured in your branch.*.remote".

Whereas "git push" does not depend on having branch.*.pushremote
configured. Its behavior is based on push.default and push refspecs, so
"what push would do" must take that into account.

> It might be useful to visualize what would be the name of the branch when
> pushing it (without a refspec) even if the publish branch hasn't been
> configured, but I think the code would be much more coplicated, and it would
> break symetry with @{upstream}, besides, the user can just do 'git push -p
> branch', and from that moment on it will be visible.

It is more complicated (see the patches that Junio had at
jk/branch-at-publish), but I think it is more likely to do what the user
expects.

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. But the branch.master.push setting does not do
anything to "git push". Only a push refspec (or push.default setting)
will change that. So the "branch.*.push" must be kept in sync manually
(perhaps by running "git push -p").

Whereas if @{publish} means "where you would push to", then
"branch.*.push" does not need to exist at all. The values can be taken
automatically from the other push settings.

-Peff

PS I first tried just setting "branch.master.pushremote" without setting
   "branch.master.push". This results in a segfault, as branch_get()
   assumes that push_name is always set and tries to xstrdup() it.

  reply	other threads:[~2014-04-11 11:18 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 [this message]
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
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=20140411111750.GA28858@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=artagnon@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=john@szakmeister.net \
    --cc=matthieu.moy@imag.fr \
    /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).