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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Apr 11, 2014, 13:48 UTC
Message-ID: <20140411134801.GB5871@nysa.casa.local>
In-Reply-To: <20140411111750.GA28858@sigill.intra.peff.net>

Jeff King wrote:

Show 10 quoted lines

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

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.

Show 8 quoted lines

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

Show 23 quoted lines

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