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

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

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.