On Mon, Jun 24, 2013 at 9:46 AM, Ramkumar Ramachandra
<artag...@gmail.com> wrote:
> Johan Herland wrote:
>>> +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).

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

Reply via email to