Re: 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 3, 2007, 14:47 UTC
Message-ID: <20070203144725.GK5362@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <b0943d9e0702030416t4088e7e1yaf2ac0a4c30def8d@mail.gmail.com>

On Sat, Feb 03, 2007 at 12:16:47PM +0000, Catalin Marinas wrote:

Show 21 quoted lines

> Yann,
> 
> On 02/02/07, Yann Dirson <ydirson@altern.org> wrote:
> >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.

As noted elsewhere, I have misinterpreted the branch.*.merge parameter; I'm trying to get things right.

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

There are 2 issues there:

- support for running atop previous releases of Git. For this we
should select a policy like "we support the current stable branch (or
to-be-published, like 1.5.0), and the previous (ie. 1.4.4.x or
1.4.x)", and document that in the release notes so packagers can
update their dependencies.

- and continue to work with repos created with old releases.  For the
"pull" change, what's needed (or should be, modulo bugs such as this
one), is to tell people they need to "git config" the missing info
when it's not there.  I have tried to keep the old behaviour as much
as possible (ie. relying on the user to pass the info on command-line)
instead of insisting on the user providing the info in the config
file, but this work is probably not 100% finished.

> 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

Right, it is reasonable to keep the old behaviour the default for now.

> 'pull' doesn't currently work.

I'll still try to make it work nevertheless before the release :)

Best regards,

-- 
Yann.