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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 17, 2015, 17:45 UTC
Message-ID: <xmqqsie4300s.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150217104628.GA25978@peff.net>

Jeff King <peff@peff.net> writes:

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

Is that because push_default variable needs to be looked at from sha1_name.c when resolving "@{push}", optionally prefixed with the name of the branch? I wonder if that codepath should know the gory details of which ref at the remote the branch is pushed to and which remote-tracking ref we use in the local repository to mirror that remote ref in the first place?

What do we do for the @{upstream} side of the things---it calls branch_get() and when the branch structure is returned, the details have been computed for us so get_upstream_branch() only needs to use the information already computed. The interesting parts of the computation all happen inside remote.c, it seems.

So we probably would do something similar to @{push} side, which would mean that push_default variable and the logic needs to be visible to remote.c if we want to have the helper that is similar to set_merge() that is used from branch_get() to support @{upstream}.

Hmmm, I have a feeling that "with default configuration, where does 'git push' send this branch to?" logic should be contained within the source file whose name has "push" in it and exposed as a helper function, instead of exposing just one of the lowest level knob push_default to outside callers and have them figure things out.

Viewed from that angle, it might be the case that remote.c knows too much about what happens during fetch and pull, but I dunno.