Junio C Hamano <gitster@xxxxxxxxx> writes:
> Carlos Martín Nieto <cmn@xxxxxxxx> writes:
>
>> From: Carlos Martín Nieto <cmn@xxxxxxx>
>>
>> We need to consider that a remote-tracking branch may match more than
>> one rhs of a fetch refspec.
>
> Hmph, do we *need* to, really?
>
> Do you mean fetching one ref on the remote side and storing that in
> multiple remote-tracking refs on our side? What benefit does such
> an arrangement give the user? When we "git fetch $there $that_ref"
> to obtain that single ref, do we update both remote-tracking refs?
> When the user asks "git log $that_ref@{upstream}", which one of two
> or more remote-tracking refs should we consult? Should we report
> an error if these remote-tracking refs that are supposed to track
> the same remote ref not all match? Does "git push $there $that_ref"
> to update that remote ref update all of these remote-tracking refs
> on our side? Should it?
>
> My knee-jerk reaction is that it may not be worth supporting such an
> arrangement as broken (we may even want to diagnose it as an error),
> but assuming we do need to, the approach to solve it, i.e. this...
>
>> In such a case, it is not enough to stop at
>> the first match but look at all of the matches in order to determine
>> whether a head is stale.
>
> ... sounds sensible.
Having said that, if we need to support such a configuration, I
would not be surprised if there are many other corner case bugs
coming from the same root cause---query_refspecs() does not allow us
to see more than one destination. It would be prudent to squash
them before we officially say we do support such a configuration.
Thanks.
--
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