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

[Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>]

On 5 May 2010 17:40, Robert Buck <buck.robert.j@gmail.com> wrote:
>
> 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 =)