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