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

On Fri, Feb 02, 2007 at 07:07:06PM +0100, Yann Dirson wrote:

On Fri, Feb 02, 2007 at 09:58:06AM +0000, Catalin Marinas wrote:

quoted

On 01/02/07, Yann Dirson [off-list ref] wrote:

quoted

Previously we were just assuming that the remote from which we
just failed defined a local branch whose name was the same as the
remote def, and that this branch was the parent.  While this is true
for the most common case (branch "origin" from remote "origin"), it is
quite an unflexible assumption.

The t1200-push-modified.sh test fails after applying this patch. It
looks like the 3rd test fails to pull the changes from 'foo' into
'bar'.

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).

Isn't that a git-clone bug ?

Now, it looks like without this patch, the post-fetch rebasing only
worked by chance, even more than I thought.

Best regards, 
-- 
Yann.