Re: [PATCH 2/4] push: make upstream, simple work with pushdefault

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 10, 2013, 19:09 UTC
Message-ID: <7vobbdhjeg.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0mfWs3LBocvn=QMcX0_ZCROx4Nw=+xjpCbKLQU0JzSdXg@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 11 quoted lines

>> I am not saying that you have to pick one to use for push.default
>> among the remaining ones (i.e. matching, current, what else?).  It
>> is very plausible that the triangular workflow wants a different
>> logic to pick what branches are to be updated and how.  Perhaps we
>> would want something that is capable of mapping your local branch
>> name to a branch name suitable in your publishing repository, and I
>> am not opposed to have such a mode.
>
> Okay, we'll have to do some sort of split and mark push.default =
> upstream/ simple suitable-only-for-centralized-workflows, or something
> to that effect (deprecation?) :|

Among the current ones, I think "upstream" is the only one that has the "branch I fetch and integrate with is the one I want to update with my result" connotation. The "current" and "matching" modes determine what gets pushed solely between the local repository you are pushing from and the remote repository you are pushing to, without getting "what do I fetch and integrate with" in the equation.

As an extension to "upstream", the current implementation of "simple" of course has the same issue, but because the name "simple" does not inherently have such "branch I fetch and integrate with is the one I want to update with my result" connotation, we can clean up its semantics to match the new reality after triangular workflow.

If you recall the earlier discussion on "@{publish} which is different from @{upstream}", one idea to allow mapping on the push end was to introduce "push.default = single" that would act as "upstream" when in "branch I fetch and integrate with is the same branch at the same repository the one I want to update with my result" workflow, and in a triangular workflow maps the branch being pushed using remote.$name.push refspecs (if exists).

I think extending it further to act as 'current' if no push refspecs are set for the remote you push to in a triangular workflow might be a way to go if we want the mapping flexibility without having to set branch.$name.push to each and every branch.