git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: LordSmoke <dslice@morphometrics.org>
To: git@vger.kernel.org
Subject: Re: Sharing nested subparts of large repository?
Date: Wed, 28 Mar 2012 10:52:18 -0700 (PDT)	[thread overview]
Message-ID: <1332957138457-7414676.post@n2.nabble.com> (raw)
In-Reply-To: <1332693502389-7403743.post@n2.nabble.com>

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.

  parent reply	other threads:[~2012-03-28 17:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-25 16:38 Sharing nested subparts of large repository? LordSmoke
2012-03-26  4:07 ` Phil Hord
2012-03-26 20:43   ` Dennis E. Slice
2012-03-28  9:52 ` Neal Kreitzinger
2012-03-28 17:52 ` LordSmoke [this message]
2012-03-29 20:05   ` LordSmoke
2012-04-05  8:32   ` LordSmoke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1332957138457-7414676.post@n2.nabble.com \
    --to=dslice@morphometrics.org \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).