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

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

Yann Dirson [off-list ref] writes:

quoted

On Fri, Feb 02, 2007 at 11:25:28PM +0000, Catalin Marinas wrote:

quoted

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.