On Tue, Feb 26, 2013 at 9:04 AM, Ben McCann <b...@benmccann.com> wrote:
> I'm fairly new to git and am trying to determine if git subtree would
> be helpful for managing our company's codebase, which has several
> repos some of which depend on each other. All the examples I've seen
> make sense to me as a one-time operation to merge separate repos into
> one monolithic one or to split one monolithic repo into separate
> repos. I'm having a harder time understanding how this fits into a
> larger picture and what the workflow for working with subtree would
The git subtree command does support pushing and pulling changes
to/from a subtree to a remote repo. This operation can be repeated
over time as the underlying git subtree split command produces an
accurate extract from the subtree.
$ git clone $superrepo super
$ cd super
$ git subtree add --prefix=child $childrepo master
$ split_head=$(git subtree split --prefix=child)
git subtree split creates a synthetic copy of the child subtree and
returns the SHA1 for the head of that subtree.
$ cd ..
$ git clone $childrepo child
$ cd child
$ child_head=$(git rev-parse master)
$split_head and $child_head match.
You could pass either $*_head to gitk and be able to browse identical
trees and histories.
$ gitk $child_head &
$ cd ../super
$ gitk $split_head &
The only difference you should see is that the tree in the super
project doesn't have any branches or tags from the child repo.
> If I have a bunch of repos on GitHub and some depend on each other,
> how would I set them up to work with subtree? Would GitHub continue to
> host them as is, host a merged monolithic repo, or host both a
> monolithic repo and the splitted out repos? The exact answer probably
> varies, but I imagine there's basic workflow that would satisfy 80% of
> users. If I have GitHub host both monolithic and splitted out repos,
> it seems unclear as to how I keep those repos in sync and make sure
> all the developers in our company push their changes to both repos.
This is what I'm using git-subtree for. I have a super project which
holds child repos, some of which hold other child repos. You can
develop on all of your projects within the super project and still
periodically pull and push updates with the remote child repos.
Someone who doesn't know about your child repos can take the
monolithic repo and commit to it as normal. You can then pull their
commits and push any changes to the child repos. Probably to a
non-master branch so you they can be integrated like other pull
1) I would probably avoid the --squash option as I suspect that might
mess with $split_head == $child_head. Whether or not it would have any
impact of your ability to push or pull I don't know. I've not tried
2) When you commit you should ideally not commit a set of files that
are in more than one subtree. You're commit history when you push back
to the source repo for a subtree might look a bit odd if it's
referring to other parts of the super project or it's subtrees.
Paul [W] Campbell
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