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

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

[Robert Buck]

Yesterday I forwarded a question related to setting up public
repositories and flows. Related to that question, and central to one
point I do not understand, is not so much the role of origins, but
rather their application.

Given the following scenario, who defines origins, and where?

repositories : product.git, product-next.git,
product-story-or-module.git, product-maint.git

The idea here would be to have product-next.git and product-maint.git
repositories to be public repositories forked from product.git.

What I have read in the Oreilly Git book is that when you `init
--bare` there are no defined remotes, nor are there any branches. So
how specifically should these repositories be set up?

Here is a guess, but likely incorrect...

Master:

git init --bare product.git
git init product-init.git
cd product-init.git
git remote add origin ../product.git
touch README
echo "hello world" > README
git add README
git commit -m "initial checkin"
git push origin master

Next:

git clone --bare --no-checkout product.git product-next.git
cd product-next.git
git remote add upstream ../product.git

Comments:

When I create a local clone of "next" and inquire about remote refs,
there are none for "upstream". What I had thought was that by adding
in predefined remote refs into the forked repository itself that when
developers clone from it they would get those predefined refs for
free, so they could immediately make use of "upstream" in push/pull
operations.

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

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

[Dmitrijs Ledkovs]

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 =)