On Sat, Feb 03, 2007 at 03:01:59PM -0800, Junio C Hamano wrote:
> Yann Dirson <ydirson@xxxxxxxxxx> writes:
>
> > On Fri, Feb 02, 2007 at 11:25:28PM +0000, Catalin Marinas wrote:
> >> OK, tried again and 'stg pull' doesn't update the base with the last
> >> patch in the series ('stg rebase origin' updates it). I don't have
> >> anything set up in my gitconfig in this area.
> >
> > So now that this particular problem has a fix, let's fix everything
> > related.
> >
> > Since branch.*.merge accept local ref names, there is probably far
> > more to change that what I initially feared.
>
> If that is the case maybe we should fix branch.*.merge not to
> match the local tracking branch name. Matching it with local
> tracking branch name when the remote name does not match was
> werely a fallback to help broken configurations confused people
> might create by hand, and has never been the part of sane
> practice at all.
Oh, sorry, I indeed meant "less to change" :>
Since git-fetch alone makes the decisions (so no algorithm has to get
duplicated into stgit), and since the only remote refs possibly
confused for local ones are the old non-separate ones, and since in
that case usually the remote branches are mapped to the same name, the
odds for a problem are low, and will get lower.
Making branch.*.merge not understand local refs, OTOH, would require
stgit to resolve a local branch to its remote name. Note that I
already had to do the job to guess which remote a branch was pulled
from (and thus, to decide whether a branch was local or remote).
Fortunately, all of this is going to be unnecessary on newer repos
since git-clone now fills all the fields - we only have to deal with
the upgrade of older repos.
Best regards,
--
Yann.
-
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