Re: Sharing nested subparts of large repository?

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.