Re: Project- vs. Package-Level Branching in Git

In message <15B7CA2E-C584-4563-B9E3-D80861CD9565@shaggyfrog.com>, Thomas Hauk w rites:

    On Jan 27, 2011, at 12:53 PM, Ævar Arnfjörð Bjarmason wrote:
    > You'll be much better off if you have project-specific repositories.

    But how often do you have a project that has no external or
    internal dependencies on any other packages or libraries? Any
    project I've ever done, big or small, has relied on some existing
    codebase. Imagine a project that uses liba and libb, which both
    reference libc. To use Git, I'd have to have copies of libc
    existing in three repositories, and copies of liba and lib in two
    repositories each. What a nightmare... and that's only a trivial
    hypothetical example.

Including libs in the superproject is the subtree merge method. It certainly works and provides inband commit exploration (since one repo can see all commits), but it inconvenient to update and even harder to export changes back to share with other liba users. It may also cause the repo to be inconveniently large. Arranging for the correct commits to be on the differently named branches (between the subproject and the superproject) is also not convenient.

git-submodule is the normal approach for the problem you have. There is a strong binding from each commit in the superproject to commits in the subprojects. What is inconvenient is managing what branch you need to check out on the subproject in order to get or make the right changes in the right place. It is also annoying if you are performing active development on the subprojects since you continually have to update the superproject and then recheckout the correct branches on the subproject.

Another solution is gitslave (http://gitslave.sf.net). This provides a loose binding from the superproject to the subprojects which is very convenient if you are doing active development on all of the subprojects. Specifically there is only a strong binding when you tag (since you tag the superproject and all subprojects at the same time). Generally, however, you check out the same branch/tag on all branches at the same time, which obviously does not match your preferred usage, except it gave me an idea. Specifically, you could have your own local master bare repositories for those packages and an orthogonal naming scheme for branches and tags. So the project foo would might have branch foo-2.0 and liba libb and libc would all have those branches as well. When you want to update libb, a repo with the true master upstream and the local master upstream would fetch the true master and merge the changes from the correct branch into foo-2.0 and then push to the local upstream master. Everyone else would then just `gits pull` and would get the changes.

Of course this concept for a local master would work for submodules as well, depending on whether you want the tight binding and update/change annoyance or the loose binding and easier update/changes.

					-Seth Robertson