In message <15B7CA2E-C584-4563-B9E3-D80861CD9565@xxxxxxxxxxxxxx>, 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
--
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