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