Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

From: Jeff King <peff@peff.net>
Date: Jan 29, 2009, 04:02 UTC
Message-ID: <20090129040254.GD11836@coredump.intra.peff.net>
In-Reply-To: <20090129035138.GC11836@coredump.intra.peff.net>

On Wed, Jan 28, 2009 at 10:51:38PM -0500, Jeff King wrote:

Show 10 quoted lines

> But:
> 
>   $ (cd child && git pull)
>   You asked me to pull without telling me which branch you
>   want to merge with, and 'branch.master.merge' in
>   ...
> 
> So it's not quite seamless. The problem is that we're not setting up the
> branch.master.* config on the empty clone. Nor do we set up
> refs/remotes/origin/HEAD.

Hrm. I was thinking we checked out "master" as a branch yet to be born, but of course that doesn't work because we don't even know that the name "master" exists on the other side (to do that, we would need an extension to transmit symref information for a ref yet to be born).

We could always assume the remote side is going to eventually put content on "master" (we know they aren't using another branch _now_, or the repo wouldn't be empty, so we are just guessing they will follow the usual convention). That feels a bit hack-ish, though.

So the current behavior is probably sane. But it is not obvious to a user how to extend their repo one the upstream isn't empty. Maybe the "empty repo" warning could mention "git fetch && git checkout -b master origin/master" (which is the most obvious way I can think of)?

-Peff