Re: [RFH] An early draft of v1.5.0 release notes

From: Junio C Hamano <junkio@cox.net>
Date: Dec 28, 2006, 02:58 UTC
Message-ID: <7v64bw3ewk.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200612271206.kBRC6ke2004207@laptop13.inf.utfsm.cl>

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

Show 8 quoted lines

> Junio C Hamano <junkio@cox.net> wrote:
>> This is still rough, but I think we have a pretty good idea what
>> will and what won't be in v1.5.0 by now, and end-of-year is a
>> good slow time to summarize what we have done.
>
> Could somebody please summarize how to "upgrade" a repository to the new
> layout?  This has got my head spinning... and I'm /not/ cloning the
> various repos I've got here just to take advantage of the changes.

The old layout was to map remote branch $B to local tracking branch .git/refs/heads/$B, unless $B == 'master' in which case it was mapped to .git/refs/heads/origin (and I think we discarded 'origin' at remote).

Each remote branch $B is tracked with .git/refs/remote/origin/$B in the new layout.

And you will get something like this in your .git/config:

    [remote "origin"]
            url = git://git.kernel.org/pub/scm/.../torvalds/linux-2.6.git/
            fetch = refs/heads/*:refs/remotes/origin/*
    [branch "master"]
            remote = origin
            merge = refs/heads/master

The first section defines what the token 'origin' means when you say "git pull origin" or "git fetch origin". remote.origin.url defines the URL to fetch/pull from, and remote.origin.fetch supplies the refspecs you omitted from the command line (fetch everything from refs/heads/ hierarchy of remote and store them in my refs/remotes/origin/ hierarchy).

The second section defines what happens when you say "git pull" or "git fetch" while on your "master" branch. It tells that you meant to say "git pull origin" or "git fetch origin" when you omitted the URL argument from the command line. And because you are also omitting the refspecs, remote.origin.fetch kicks in and slurps all the branches from the remote side and stores them in your refs/remotes/origin/ hierarchy. When the command was "git pull", it also says the merge that follows the fetch is to merge the 'master' branch at the remote side (which happens to be copied to your remotes/origin/master only because you have remote.origin.fetch) into your current branch (which is "master", because this section is about what happens while you are on your "master" branch).

So for an existing repository that does not use the separate remotes layout, you can easily convert that by hand if you wanted to by:

 - Move tracking branches from refs/heads/* to
   refs/remotes/origin/*,

 - create the config section like the above in .git/config, and

 - remove .git/remotes/origin when you are done.