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.
--
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