Might also look at the git submodule stuff for a case like Diva's where you really want a separate repo but it's attached to another tree. That is, the git tip at the main repo has core code and the submodules refer to separate trees with dependant but not mainline features.
Mike http://git.or.cz/gitwiki/GitSubmoduleTutorial -----Original Message----- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mike Mazur Sent: Monday, August 03, 2009 8:14 AM To: d...@metaverseink.com; opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Q about Git in practice Hi Diva, On Mon, Aug 3, 2009 at 02:25, <d...@metaverseink.com> wrote: > Here's the situation: I'm working on the new, CAPS-based HG Inventory > service. As an inventory service, it's an alternative to the one that we > currently have (OpenSim.InventoryService.dll and associated > handlers/modules), it's completely different, designed for different > clients. One way to achieve this, though perhaps not the best way, is to have a branch with your changes based on the trunk. So, let's assume the current trunk is a branch called "master" in the repo you clone from opensimulator.org. This repo on opensimulator.org will is referred to as "origin" in the repo local to your hard drive. First, you'd clone the remote repo: $ git repo d...@opensimulator.org/opensimulator.git $ git branch * master Running `git branch` displays the branch you're currently checked out into your workspace. Then, you'd create your own branch for your feature: $ git branch new_caps $ git checkout new_caps $ git branch * new_caps master This creates a branch in your local repo called "new_caps". You check out this branch, which means that your working directory now reflects the state of this branch. At this point it's identical to "master". Now you hack away at your feature, making commits as you progress. $ ... edit ... $ git commit $ ... edit some more ... $ git commit $ ... etc ... You'll end up with something like this: master O---O---A---B---C \ new_caps D---E---F where A is the commit at which you created the "new_caps" branch from "master", B and C are commits that have been applied to the "master" branch by you or others, and E and F are some commits you made to the "new_caps" branch you're working on. At this stage, you want to bring your branch up-to-date with what's going on in "master". `git rebase` is perfect for the job. First we pull any new commits that exist on opensimulator.org to your local repository: $ git checkout master $ git pull Now we will rebase the commits in "new_caps" on top of the most recent commit in "master" $ git checkout new_caps $ git rebase master Now your commit history will look like this: master O---O---A---B---C \ new_caps D---E---F What git does is it finds the first common commit between "new_caps" and "master", which is A. Then, it takes all the commits in "new_caps" since A and applies them to the tip of "master", in order. When it's done, your branch has all your changes, and it's up-to-date with all the changes in OpenSim trunk :) If there are any conflicts when you rebase, you'll be given the opportunity to resolve them and continue on once you've done so. Hope that helps, Mike _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev