Re: [PATCH 2/2] fetch: handle overlaping refspecs on --prune

Carlos Martín Nieto [off-list ref] writes:

From: Carlos Martín Nieto <redacted>

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.