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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 27, 2014, 20:19 UTC
Message-ID: <xmqqob1sxq8v.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1393491610-19476-2-git-send-email-cmn@elego.de>

Carlos Martín Nieto <cmn@elego.de> writes:

> From: Carlos Martín Nieto <cmn@dwim.me>
>
> 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.