On 11-01-27 06:22 PM, Thomas Hauk wrote:
> 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.
Let me try to give you a more positive response... :)
Where I work, our products rely on a vast amount of code from different
sources, not just various internal and external libraries but also the entire
FreeBSD tree as well as assorted forks of different Linux kernel versions
(because different customers have their own tweaked kernels that we need to
work with).
We use git in a variety of ways to manage all this. We rely a lot on git's
submodule feature, but not exclusively.
For most external code, including the Linux kernel forks, we usually set up
an internal git mirror of whatever public repository the code has. So each
external code base has its own git repository, and we attach those
repositories to our main repo using submodules.
This works fairly well, especially because we don't update the external
sources very often. Working with submodules takes a bit of getting used to,
but it works nicely when the different pieces are reasonably independent, and
this is usually the case for external libraries.
For our internal libraries, we just keep them all in the main repository.
Our internal code does have some inter-dependencies, so it's convenient to
track them all together. Note that this doesn't prevent internal libraries
from evolving independently -- even though a branch applies to the whole
repo, the branch's _topic_ can just be about one specific library. Anyone
who needs to use the library's updated code can merge that branch into their
own, or base their work on that branch. Eventually the library's branch gets
merged back into the mainline branch and everyone gets to use the updated code.
In addition to all that, we have a different way of working with the FreeBSD
code base. This was put together a few years ago, and I would do it
differently now, but I'll describe it to give you an idea of what else is
possible with git.
The FreeBSD code tree lives in a subdirectory of our main repo. It's not a
submodule or anything fancy, it's just the code. We've modified the FreeBSD
code quite a bit, but we also keep it up to date with changes the FreeBSD
guys make. We put all of their changes in a separate branch in our main
repo, and a script keeps that branch up to date. When we're ready, we merge
the FreeBSD changes into our mainline branch.
Keeping that FreeBSD branch up to date is a bit involved. The branch
actually reflects a single branch in the FreeBSD public subversion
repository. We use "git svn" to maintain a git mirror of that subversion
branch, and what our script does is compare the latest FreeBSD subversion
revision number in our main repo to the one in the mirror ("git svn" records
the subversion revision numbers in the git commits it creates). When the
script finds that the main repo is out of date, it extracts the patches for
each individual subversion commit and applies them as git commits in our main
repo's FreeBSD branch. (Any git veterans who've read this far are probably
cringing right now...)
Anyway, my point is that git provides a lot of flexibility to let you work
with your code base in many different ways, but none of them are how
subversion or perforce work. Coming from those tools, you have to shift your
mindset a bit to make the best use of git. That can be frustrating, and I
won't say that git's model is The One True Way, but I've found that what feel
like limitations from the perspective of other tools usually turn out to be
relatively inconsequential.
M.
--
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