Sharing nested subparts of large repository?

Sharing nested subparts of large repository?

[LordSmoke]

I've been using git for a couple of months to get used to the system. Basic
stuff - a few larger project repositories in unique directories, commits,
pushes to a remote repository. Mostly as a kind of backup system.

However, my ultimate goal is to share part of one large project currently
being managed with git with my developers. I want them to have access to
source code and test data, but not my manuscripts, correspondence, whatever.

I also want to make a portion of what I will give my developers available as
open source, e.g., on github, but not all of it. Just the stable,
non-developmental parts. NOT the our development stuff and not the parts
being used for private contracts.

Submodules seem promising, but the examples are not quite what I am looking
for, as far as I can tell. They talk about isolating submodules that depend
on a larger project. I want to make available the larger project while
keeping nested submodules (so to speak) private.

Would someone point me in the right direction to achieve my goals?

TIA


--
View this message in context: http://git.661346.n2.nabble.com/Sharing-nested-subparts-of-large-repository-tp7403743p7403743.html
Sent from the git mailing list archive at Nabble.com.

Re: Sharing nested subparts of large repository?

[Phil Hord]

On Sun, Mar 25, 2012 at 12:38 PM, LordSmoke <dslice@morphometrics.org> wrote:
> I've been using git for a couple of months to get used to the system. Basic
> stuff - a few larger project repositories in unique directories, commits,
> pushes to a remote repository. Mostly as a kind of backup system.
>
> However, my ultimate goal is to share part of one large project currently
> being managed with git with my developers. I want them to have access to
> source code and test data, but not my manuscripts, correspondence, whatever.
>
> I also want to make a portion of what I will give my developers available as
> open source, e.g., on github, but not all of it. Just the stable,
> non-developmental parts. NOT the our development stuff and not the parts
> being used for private contracts.
>
> Submodules seem promising, but the examples are not quite what I am looking
> for, as far as I can tell. They talk about isolating submodules that depend
> on a larger project. I want to make available the larger project while
> keeping nested submodules (so to speak) private.
>
> Would someone point me in the right direction to achieve my goals?

There's a blog post detailing a similar workflow here:
http://www.braintreepayments.com/devblog/our-git-workflow

Grr... I think they used to have a section on keeping some parts of
the project "forever private", but I don't see that now.

Phil

Re: Sharing nested subparts of large repository?

[Dennis E. Slice]

On 3/26/12 12:07 AM, Phil Hord wrote:
> On Sun, Mar 25, 2012 at 12:38 PM, LordSmoke<dslice@morphometrics.org>  wrote:
<...snip...>
>>
>> Would someone point me in the right direction to achieve my goals?
>
> There's a blog post detailing a similar workflow here:
> http://www.braintreepayments.com/devblog/our-git-workflow

Yes. That is exactly where I was heading in thinking about things and 
learning more about branches. gitx or gitg really help clarify the 
relationships and allow one to think better about the organization. I 
had looked at all this early on, but was too new to be anything other 
than confused. I have enough experience now to appreciate at least some 
of it.

TIA

>
> Grr... I think they used to have a section on keeping some parts of
> the project "forever private", but I don't see that now.
>
> Phil
>
>

Re: Sharing nested subparts of large repository?

[Neal Kreitzinger]

On 3/25/2012 11:38 AM, LordSmoke wrote:
> I've been using git for a couple of months to get used to the system.
> Basic stuff - a few larger project repositories in unique
> directories, commits, pushes to a remote repository. Mostly as a kind
> of backup system.
>
> However, my ultimate goal is to share part of one large project
> currently being managed with git with my developers. I want them to
> have access to source code and test data, but not my manuscripts,
> correspondence, whatever.
>
> I also want to make a portion of what I will give my developers
> available as open source, e.g., on github, but not all of it. Just
> the stable, non-developmental parts. NOT the our development stuff
> and not the parts being used for private contracts.
>
> Submodules seem promising, but the examples are not quite what I am
> looking for, as far as I can tell. They talk about isolating
> submodules that depend on a larger project. I want to make available
> the larger project while keeping nested submodules (so to speak)
> private.
>
It sounds like maybe your superproject has all the submodules and their
superproject has only some of the submodules.  You can also have a 
superproject just like theirs so you have a superproject with everything 
(because your special) and another superproject like theirs (so you can 
pretend to be just like them).

I'm not a submodule expert, but I'm pretty sure you can do that. 
Whether or not that matches up with your current structure of various 
git repos or not I don't know (enough details).

v/r,
neal

Re: Sharing nested subparts of large repository?

[LordSmoke]

Thanks for the helpful replies. It does seem that branches will do what I
want. Yesterday, I organized my files and created an (eventually)
open-source startup project (distinct from the development application
startup).

I created a branch "development" and "git rm"'d the (many) files I didn't
want to pass along to my developers. The trick here, I think, is you have to
do an initial commit before the rm's or else it will affect the master...or
something. Anyway, I had to reset and try a couple of times, but in the end
it worked. 

After checking out that branch, I created "public", initial commit, then
rm'd the development startup project and the other files I wouldn't want to
post to the world.

I also managed to push these branches to my remote repository. Add them to
my office repository as tracked branches, and test cloning, It works just as
I had envisioned - cloning the public branch produces the minimal structure.

I think I am two steps away from complete satisfaction. Not related to this,
I have some files that are reluctant to be updated, added, tracked, or
untracked, but that's a different issue. 

Now, though, I am wondering about merging the changes across branches. Say I
make changes on the development branch. If I merge that into the master,
will the reduced tracking be merged? - don't want that. If I merge the other
way - from, say, checkout public and merge in development? Will a bunch of
other stuff come over?

Anyway, that is where I am now and what I am looking into. Very happy with
progress, so far.

Oh, while I do everything from the command line, seeing it graphically with
gitx has really helped me conceptualize what is going on. All of this has
given me a much better understanding of what is going on in the little time
I have been able to spend on it. 

--
View this message in context: http://git.661346.n2.nabble.com/Sharing-nested-subparts-of-large-repository-tp7403743p7414676.html
Sent from the git mailing list archive at Nabble.com.

Re: Sharing nested subparts of large repository?

[LordSmoke]

Drat! I got my branches set up the way I wanted, but basic merge
restores/deletes files depending upon what I am merging with what. E.g.,
"master" <-merge- "development" deletes master's files I want to keep,
"development" <-merge- "master" adds back in the files I took out of
"development". Perhaps some merge options.

Still looking... 8-/


--
View this message in context: http://git.661346.n2.nabble.com/Sharing-nested-subparts-of-large-repository-tp7403743p7419114.html
Sent from the git mailing list archive at Nabble.com.

Re: Sharing nested subparts of large repository?

[LordSmoke]

Okay, it seems submodules really were the answer. I split my app into a
standalone public subtree and a development subtree that will use the public
source as a submodule (haven't actually done that yet, though). These will
be excluded from the parent git repository, but I guess that is fine since
the parent is used mainly for archiving and the remote repository serves as
the code archive.

--
View this message in context: http://git.661346.n2.nabble.com/Sharing-nested-subparts-of-large-repository-tp7403743p7439149.html
Sent from the git mailing list archive at Nabble.com.