public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed

From: Junio C Hamano <gitster@pobox•com>
To: "Carlos Martín Nieto" <cmn@elego•de>
Cc: git@vger•kernel.org
Subject: Re: [PATCH 2/2] fetch: handle overlaping refspecs on --prune
Date: Thu, 27 Feb 2014 12:41:21 -0800	[thread overview]
Message-ID: <xmqqbnxsxp8u.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <xmqqob1sxq8v.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Thu, 27 Feb 2014 12:19:44 -0800")

Junio C Hamano <gitster@pobox•com> writes:

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

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.

next prev parent reply	other threads:[~2014-02-27 20:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27  9:00 [PATCH 1/2] fetch: add a failing test for prunning with overlapping refspecs Carlos Martín Nieto
2014-02-27  9:00 ` [PATCH 2/2] fetch: handle overlaping refspecs on --prune Carlos Martín Nieto
2014-02-27 10:21   ` Michael Haggerty
2014-02-27 19:29     ` Carlos Martín Nieto
2014-02-27 20:19   ` Junio C Hamano
2014-02-27 20:41     ` Junio C Hamano [this message]
2014-02-28 12:21     ` Carlos Martín Nieto
2014-02-28 18:04       ` Junio C Hamano
2014-03-24 19:24   ` Junio C Hamano
2014-02-27 20:18 ` [PATCH 1/2] fetch: add a failing test for prunning with overlapping refspecs Eric Sunshine
2014-02-27 20:19 ` Eric Sunshine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqbnxsxp8u.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=cmn@elego$(echo .)de \
    --cc=git@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox