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 2, 2007, 23:56 UTC
Message-ID: <20070202235655.GG5362@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <20070202180706.GE5362@nan92-1-81-57-214-146.fbx.proxad.net>

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

Show 11 quoted lines

> On Fri, Feb 02, 2007 at 09:58:06AM +0000, Catalin Marinas wrote:
> > On 01/02/07, Yann Dirson <ydirson@altern.org> wrote:
> > >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.