Re: [PATCH v2 6/9] branch: display publish branch

Jeff King wrote:

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

quoted

quoted

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.

I think it is. @{publish} is like @{upstream}. Period.

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".

And I disagree.

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.

Yes, but we are not talking about 'git push', we are talking about
@{publish}.

I think of @{publish} as "the branch the user has configured to push
to"; it overrides all other configurations (push.default and push
refspecs). I wouldn't mind having a @{push} *in addition* to @{publish}
that would have the behavior you mention, but for @{publish} I'm pretty
certain the behavior I want is that it maps *directly* to what the user
has configured.

Similarly, I don't want 'git branch -vv' to show @{push}; it would be a
mess to show something on all the branches, probably origin/$branch, and
probably all "ahead/behind". I want it to show @{publish}, so only the
branches the user has *explicitly* configured.

quoted

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"

It doesn't mean that to me.

For the record, I've been thinking about this for a long long time, and
I argued for @{push} and @{publish} long before you discussed this in
January (which apparently you forgot). I implemented this more than half
a year ago, and have been using it since; it works great. The problem of
triangular workflows is pretty much solved for me.

-- 
Felipe Contreras