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

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Feb 3, 2007, 12:16 UTC
Message-ID: <b0943d9e0702030416t4088e7e1yaf2ac0a4c30def8d@mail.gmail.com>
In-Reply-To: <20070202235655.GG5362@nan92-1-81-57-214-146.fbx.proxad.net>

Yann,

On 02/02/07, Yann Dirson <ydirson@altern.org> wrote:

Show 15 quoted lines

> 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 <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":

As I haven't followed the GIT latest developments in this area, I can't comment. Regarding StGIT, I'd like it to work with earlier stable versions of GIT and not just with the current HEAD. I (and probably many others) already have repositories cloned some (long) time ago and their gitconfig might not have the cloning information.

The (interim) solution I see is for StGIT pull command to default to using git-pull and people can configure it to git-fetch and the automatic rebase if they need it. I'd like to release 0.12 this weekend but 'pull' doesn't currently work. Are you OK with my solution (for backward compatibility with older repositories and GIT versions)?

Thanks.

-- 
Catalin