Re: [PATCH 2/2] fetch: handle overlaping refspecs on --prune
- From
Carlos Martín Nieto <cmn@elego.de>
- Date
- Feb 28, 2014, 12:21 UTC
- Message-ID
- <1393590104.5277.19.camel@centaur.cmartin.tk>
- In-Reply-To
- <xmqqob1sxq8v.fsf@gitster.dls.corp.google.com>
On Thu, 2014-02-27 at 12:19 -0800, Junio C Hamano wrote:
Show 12 quoted lines
> 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"
No, I mean a different kind of overlap, where the right-hand side matches more refs than appear on the left side. In this particular case, we would have something like
refs/heads/*:refs/remotes/origin/*
refs/pull/*/head:refs/remotes/origin/pr/*as fetch refspecs. Going remote -> remote-tracking branch is not an issue, as each remote head only matches one refspec. However, we now have 'origin/master' and 'origin/pr/5' both of which match the 'refs/remotes/origin/*' pattern. The current behaviour is to stop at the first match, which would mark it as stale as there is no 'refs/heads/pr/5' branch in the remote.
In lieu of "real" namespacing support for remotes, this seems like a reasonable way of coalescing the namespaces in the remote repo. I'll update the commit message with more exact explanation of what kind of overlap we're dealing with, as it seems it could do with help. Is there maybe a better word to describe this setup than "overlapping"?
Show 12 quoted lines
> 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...
> For this (other) situation, where you duplicate refs, the issue we're dealing with in these patches wouldn't arise. I have argued similarly against built-in support in libgit2 for this kind of shenanigans, but apparently there's people who use it, though their motivations remain a mystery to me. Luckily we can support *that* quite well by just going through the refspecs one by one and applying the rules (both in git and libgit2).
cmn
Show 5 quoted lines
> > 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.