Re: [PATCH 2/3] Rebase to parent branch after git-fetch in "stg pull".

From: Yann Dirson <ydirson@altern.org>
Date: Feb 4, 2007, 00:24 UTC
Message-ID: <20070204002439.GH4266@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <7v8xfe3kwo.fsf@assigned-by-dhcp.cox.net>

On Sat, Feb 03, 2007 at 03:01:59PM -0800, Junio C Hamano wrote:

Show 19 quoted lines

> Yann Dirson <ydirson@altern.org> 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.