Re: newbie: should git bare repositories (forked ones) have an origin defined?

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>
Date: May 6, 2010, 00:49 UTC
Message-ID: <u2n86ecb3c71005051749m95977244oa5c5ee809599dc4c@mail.gmail.com>
In-Reply-To: <q2r408104421005050940k2d054b20zad05552623ba2338@mail.gmail.com>

On 5 May 2010 17:40, Robert Buck <buck.robert.j@gmail.com> wrote:

Show 11 quoted lines

>
> Question:
>
> Is what I am inquiring about reasonable, or is there a good reason to
> not have remote refs embedded into the public forked repository?
> How should public forked repositories ("next" in the use case above)
> be initially created on its host?
>
> Thank you,
>
> Bob

"origin" & "master" are just the default names for a remote & where HEAD points to on remote repository.

A bare repository usually doesn't have any refs/remotes/* instead it just has refs/heads/*

When you clone a bare repository refs/heads/* from bare repository are pulled into refs/remotes/<remotename>/*

look at your .git/config to see how flexible this is.

you can do

[remote "qa-branches"]
      url = ../qa
      fetch = +refs/heads/qa-stable:refs/heads/stable
      fetch = +refs/heads/qa-appprove:refs/heads/next
      fetch = +refs/heads/qa-pending:refs/heads/dev

[remote "bob"]
      url = ../bob
      fetch = +refs/heads/qa-rejected:refs/heads/experimental

This repository can be public and you can have many remotes defined all fetching into refs/heads.

Now set-up bare repositories that you like and set-up as many remotes as locations you need to fetch from, figure out which heads to you need to fetch & how you want to call them and you are done =)