Thread (15 messages) flat view 15 messages, 3 authors, 2016-06-15

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

From: Jeff King <hidden>
Date: 2016-06-15 23:03:50

On Mon, Feb 16, 2015 at 12:47:54AM -0500, Jeff King wrote:
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help