Re: [PATCH 2/2] builtin/push.c: make push_default a static variable

From: Jeff King <peff@peff.net>
Date: Feb 17, 2015, 10:46 UTC
Message-ID: <20150217104628.GA25978@peff.net>
In-Reply-To: <20150216054754.GB25088@peff.net>

On Mon, Feb 16, 2015 at 12:47:54AM -0500, Jeff King wrote:

Show 16 quoted lines

> When the "push_default" flag was originally added, it was
> made globally visible to all code. This might have been
> useful if other commands or library calls ended up depending
> on it, but as it turns out, only builtin/push.c cares.
> 
> Let's make it a static variable in builtin/push.c.
>
> [...]
> 
> ---
> We know this is safe because no other callers needed tweaked when the
> variable went out of scope. :) It would only be a bad idea if we
> were planning on having other code in the future depend on push_default
> (e.g., the code in remote.c to find the push destination). But it does
> not seem to have needed that in the intervening years, so it's probably
> fine to do this cleanup now.

I had a nagging feeling that there was some code which wanted to use this elsewhere, and I did finally find it, when I merged this topic with my other personal topics.

If we wanted to implement "@{push}" (or "@{publish}") to mean "the tracking ref of the remote ref you would push to if you ran git-push", then this is a step in the wrong direction.

The patches I posted last January (and which you carried as jk/branch-at-publish for a while) do work, and I've used the feature once or twice since then. From the discussion, it looks like they were meant to be a building block for more triangular-flow work, but I don't remember what else was needed. I'm tempted to resurrect them, but it's not a high priority for me.

Anyway, food for thought on whether we want to do this cleanup or not, then. We can always leave this here as part of git_default_config, and still move Dave's new option into git_push_config.

-Peff