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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Horst H. von Brand" <vonbrand@xxxxxxxxxxxx> writes:

> Junio C Hamano <junkio@xxxxxxx> 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.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]