Repository Code Scope (Plan Text)

2015-06-24 Thread BGaudreault Brian
Hello,

What type of code scope should a repository contain?  Can it be one large 
program with many elements or should it just be part of a program or can it be 
a project with multiple programs?  What are the recommendations?

Thanks,
Brian
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: Repository Code Scope (Plan Text)

2015-06-24 Thread BGaudreault Brian
Thanks.  So are you saying there are tools that will let us start a repo for a 
project with multiple submodules and then pull out the coding history for a 
specific submodule so we can create a separate repository just for that 
submodule?

I've actually been doing a lot of research about Git for many things that Git 
doesn't have basic documentation for, but I wasn't sure how to search for an 
answer to this type of question.  Plus, we're trying to adopt Git quickly, and 
since I'm not a developer I have a lot of research that has to be done to 
understand what developers understand and how we can manage GIt, which is 
slowing down our adoption of Git.

Thanks,
Brian

-Original Message-
From: Konstantin Khomoutov [mailto:kostix+...@007spb.ru] 
Sent: Wednesday, June 24, 2015 2:53 PM
To: BGaudreault Brian
Cc: git@vger.kernel.org
Subject: Re: Repository Code Scope (Plan Text)

On Wed, 24 Jun 2015 18:19:42 +
BGaudreault Brian bgaudrea...@edrnet.com wrote:

 What type of code scope should a repository contain?  Can it be one 
 large program with many elements or should it just be part of a 
 program or can it be a project with multiple programs?  What are the 
 recommendations?

There are no recommendations because the structure of a repositories depends on 
the use case.

If you're developing a library which might be used by more than a single other 
project, host it in a separate repository, and in the projects which use that 
library, refer to it using submodules.

If you have a project which contains internal submodules (say, for .NET 
projects, it's common to have many so-called assemblies in a single project to 
provide modularity), there's little point in messing with separate repositories 
and it's simpler to keep everything in one place.

Note that there are tools which allow you to split from a repository the 
history touching only the contents of a particular directory, and then glue 
such history back into some other repository.  Using these are not exactly a 
walk in the park but at least this sort of things is doable.
This means you might start with a simple solution and then shape it into a more 
appropriate form when you'll see the need for this.

I should also warn you that your question appear to be a bit too broad which, 
IMO, suggests that you did not do much research on what's offerred by Git and 
its ecosystem, what's in a Git repo, how is it hosted, what are the best 
practices of managing complicated Git projects etc.  And all this information 
is abundant in the internets...
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Repository Code Scope (Plan Text)

2015-06-24 Thread Konstantin Khomoutov
On Wed, 24 Jun 2015 18:19:42 +
BGaudreault Brian bgaudrea...@edrnet.com wrote:

 What type of code scope should a repository contain?  Can it be one
 large program with many elements or should it just be part of a
 program or can it be a project with multiple programs?  What are the
 recommendations?

There are no recommendations because the structure of a
repositories depends on the use case.

If you're developing a library which might be used by more than a
single other project, host it in a separate repository, and in the
projects which use that library, refer to it using submodules.

If you have a project which contains internal submodules (say,
for .NET projects, it's common to have many so-called assemblies in a
single project to provide modularity), there's little point in messing
with separate repositories and it's simpler to keep everything in one
place.

Note that there are tools which allow you to split from a repository the
history touching only the contents of a particular directory, and then
glue such history back into some other repository.  Using these are not
exactly a walk in the park but at least this sort of things is doable.
This means you might start with a simple solution and then shape it
into a more appropriate form when you'll see the need for this.

I should also warn you that your question appear to be a bit too broad
which, IMO, suggests that you did not do much research on what's
offerred by Git and its ecosystem, what's in a Git repo, how is it
hosted, what are the best practices of managing complicated Git
projects etc.  And all this information is abundant in the internets...
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html