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

Robert Buck· May 5, 2010, 16:40 UTC · lore

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

Dmitrijs Ledkovs· May 6, 2010, 00:49 UTC · re: Robert Buck · lore

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

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