Johan Herland wrote:
>> An earlier round of this change by mistake broke the safety for
>> "simple" mode we have had since day 1 of that mode to make sure that
>> the branch in the repository we update is set to be the one we fetch
>> and integrate with, but it has been fixed.
>
> Shouldn't there be an acompanying test to demonstrate this mistake being fixed?
Read "earlier iteration": it didn't get merged.
>> +static void setup_push_current(struct remote *remote, struct branch *branch)
>> +{
>> + if (!branch)
>> + die(_(message_detached_head_die), remote->name);
>> + add_refspec(branch->name);
>
> Here (and above) we add a refspec to tell Git exactly what to push
> from the local end, and into what on the remote end.
Nope, we add the refspec "foo", without the :destination part. The
remote end is unspecified (and defaults to "foo", but that is in the
transport layer).
> Is it possible to
> end up with multiple simultaneous refspecs matching the same local
> ref, but mapping to different remote refs? If so, which will win, and
> does that make sense?
It is impossible. We either:
- Get an explicit refspec from the user and never run
setup_default_push_refspecs() to begin with.
- Run setup_push_refspecs() and add *one* refspec depending on the
push.default value.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html