On Mon, Jun 24, 2013 at 9:46 AM, Ramkumar Ramachandra
> Johan Herland wrote:
>>> +static void setup_push_current(struct remote *remote, struct 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).
Ok, so "foo" is not always semantically equivalent to "foo:foo", and
when adding "foo:bar" it is always considered more specific than (and
superior to) "foo". I think that makes sense.
>> 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.
Thanks, that's what I wanted to hear. But then, does it make sense to
say that we will only ever have exactly _one_ push refspec in the
current context, and we should therefore replace the "static const
char **refspec;" string array with a single "static const char
*refspec;" string? That would make it obvious that there is no room
for ambiguity with overlapping refspecs.
Johan Herland, <jo...@herland.net>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html