From: Yann Dirson Date: Sat, 03 Feb 2007 00:14:30 GMT Subject: Re: git-clone wrongly setting branch.*.merge ? (Was: [PATCH 2/3] Rebase to parent branch after git-fetch in "stg pull".) 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: > 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.