multiple branches or multiple repositories

multiple branches or multiple repositories

[Han-Wen Nienhuys]

We're in the process of converting the LilyPond CVS repository at 
savannah.gnu.org to GIT.  One of the questions we need to deal with, is 
how handle modules.

There seem to be two approaches:

  - for each module, create a separate git repository.  Inside the 
repository, each subproject has its own branching

  - put each module as a separate branch in a shared repository.

I think the first option is the most natural one, but are there any 
issues, besides namespace pollution to the second option?

-- 
  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: multiple branches or multiple repositories

[Junio C Hamano]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> We're in the process of converting the LilyPond CVS repository at
> savannah.gnu.org to GIT.  One of the questions we need to deal with,
> is how handle modules.
>
> There seem to be two approaches:
>
>  - for each module, create a separate git repository.  Inside the
> repository, each subproject has its own branching
>
>  - put each module as a separate branch in a shared repository.
>
> I think the first option is the most natural one, but are there any
> issues, besides namespace pollution to the second option?

As the layout for a distribution point, the second one may be
easier to handle (one place to remotely sync with), but in all
other aspects the first option should be easier to deal with
day-to-day.

Re: multiple branches or multiple repositories

[Linus Torvalds]

On Fri, 3 Nov 2006, Han-Wen Nienhuys wrote:
> 
> We're in the process of converting the LilyPond CVS repository at
> savannah.gnu.org to GIT.  One of the questions we need to deal with, is how
> handle modules.
> 
> There seem to be two approaches:
> 
>  - for each module, create a separate git repository.  Inside the repository,
>    each subproject has its own branching
> 
>  - put each module as a separate branch in a shared repository.
> 
> I think the first option is the most natural one, but are there any issues,
> besides namespace pollution to the second option?

There are no real issues either way, and perhaps more importantly, it's 
not even something you have to decide on day one.

You can easily do it one way or the other, and either
 - switch around as needed
 - or even _mix_ the two approaches where it makes sense.

For example, it may be entirely sensible to have the common "distribution 
points" use a single shared repository that contains all modules as 
separate branches within the same repository.

But even though such a central distribution point repository is set up 
that way, individual developers may well decide that they are happier 
having separate repositories for different modules. The two approaches are 
not mutually incompatible, and you can fetch data and push it back out 
between both different kinds of repositories.

The namespace pollution - especially of tags - is indeed likely to be the 
worst issue. If you expect to have many independent modules in the same 
repository, you obviously shouldn't use tag-names like the Linux kernel 
uses (ie "v2.6.18"), since those would not be unambiguous in such a shared 
repo. 

(The same is true of branches too, but perhaps less so if only because 
people are _already_ using different branch names between different 
repositories, and we have good support for translating a local branch 
name "X" into a remote branch name "Y" when transferring data between the 
two. In contrast, tagnames are kind of expected to be "shared")

But if you're ok with always just naming tags "modulename/release-1.2.3" 
or similar, you shouldn't really have any issues either way. And most 
importantly, if you do decide to go one way, and then later figure out 
that it would have been easier the other way, you can just switch between 
the two models, exactly because mixing them isn't really a problem.

Re: multiple branches or multiple repositories

[Jeff King]

On Fri, Nov 03, 2006 at 02:51:30AM +0100, Han-Wen Nienhuys wrote:

>  - for each module, create a separate git repository.  Inside the 
> repository, each subproject has its own branching
> 
>  - put each module as a separate branch in a shared repository.
> 
> I think the first option is the most natural one, but are there any 
> issues, besides namespace pollution to the second option?

I don't believe there is currently an option to git-clone to grab only a
single branch, so cloners in the second case would end up having to get
_all_ modules (though such an option would probably not be hard to
implement).

The plus side is that a single 'fetch' would grab updates for all
modules (with only a single connection to the server).