Re: git-clone wrongly setting branch.*.merge ? (Was: [PATCH 2/3] Rebase to parent branch after git-fetch in "stg pull".)

From: Yann Dirson <ydirson@altern.org>
Date: Feb 3, 2007, 00:14 UTC
Message-ID: <20070203001430.GH5362@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <20070202235655.GG5362@nan92-1-81-57-214-146.fbx.proxad.net>

On Sat, Feb 03, 2007 at 12:56:55AM +0100, Yann Dirson wrote:

Show 15 quoted lines

> With current GIT HEAD, plain git-clone creates the following config
> (when cloning a repo with HEAD pointing to branch "downstream":
> 
> 
> [remote "origin"]
>         url = /export/work/yann/git/stgit/tmp/.git
>         fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "downstream"]
>         remote = origin
>         merge = refs/heads/downstream
>                 ^^^^^^^^^^^^^^^^^^^^^
> 
> I would have expected "merge = remotes/origin/downstream" instead, and
> this setting confuses the rebase-after-pull logic, causing it to
> rebase the stack onto its own base (no-op).

Hm, I see I was confused about the branch.*.merge meaning. The config doc does document it to be the remote part of the refspec.

But what does that mean - why using the remote part here ? I cannot see that, although I can see arguments why using the local part here:

- When we come to finding the branch to merge, we have already fetched
all remote branches into local ones, so why would we need to find a
local branch matching this remote name ?

- How are we supposed to handle the case where a single remote ref is
mapped to several local ones ?  Although I cannot see a use for this
situation, it would seem to be a valid one, whereas having several
fetch lines for a single local ref in a single remote would clearly
be invalid: using a local ref would avoid a possible ambiguity.

Best regards,

-- 
Yann.