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

From: Yann Dirson <>
Date: 2007-02-03 10:56:55
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:
> > On 01/02/07, Yann Dirson <> 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 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, 

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at
Received on Sat Feb 03 11:01:58 2007

This archive was generated by hypermail 2.1.8 : 2007-02-03 11:03:46 EST