"Wink Saville" <wink@xxxxxxxxxxx> writes: > A couple of questions on how to manage a series of > hierarchically related branches. > > I've created something like this: > > ----> master > \----> branchA > \----> branchB > \----> branchC > > With the intent to be able to create three separate > patches that others can make to master and also continue > development on all three branches simultaneously. > > What I'm doing at the moment is to "git-checkout" > one of the three branches A, B or C and make changes. > Note; I don't make changes to master as it represents the > upstream code and will be pulling from it periodically. > > If the branch is a parent to a child and I want the > new changes in the parent to be seen by the children I > recursively check out the immediate child do a git-rebase. This depends on how you plan to ultimately use the result of work done on the topic branches. If you are feeding the completed series as a set of patches to upstream to be applied (and eventually contained when you pull into 'master'), this "master is always pristine, topics are constantly rebased on top of it" pattern is a reasonable thing to do. With a few caveats: * It is harder to share the topics across multiple people as you are constantly rebasing. * As you found out, you need to keep track of which ones come directly on top of 'master', which ones are second generation on top of which other branches, etc. You do not necessarily have to be constantly rebasing on top of 'master', though. You can instead: - Keep 'master' pristine (as your upstream does not 'pull' from you); - When you start a topic, try to fork from the branch closest to 'master' (preferrably 'master' itself); - When there are new changes on 'master' (or topic that is closer to 'master') that affect the work you did on your topic, merge 'master' into the topic, and keep going, never rebasing the topic. This 'merging from upstream as needed' includes the case where your submission was applied to 'master'. As you go, when all the work you are done on a topic has been applied to 'master', your 'merge from master' would result in the tree of that topic exactly match the tree of 'master'. At that point you can discard that topic branch. The set of changes you have on a topic that have not been applied to 'master' can be found using 'git-cherry'. > Also, I'd like to checkout and work on all three branches > simultaneously. Julian Phillips's git-new-workdir script in contrib/workdir may suit your needs. Having said all that, the first advice is to avoid second generation topic that depends on another topic when possible. Is your branchB absolutely need to depend on branchA? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html