Re: How to manage multiple personal projects

[Avery Pennarun <apenwarr@gmail.com>]

On Wed, Jul 15, 2009 at 12:00 PM, Paul Richards<paul.richards@gmail.com> wrote:
> I believe the correct choice with Git is to create a repository per
> project.  This would work OK for me, but I worry about the shear
> number of repositories I'd end up creating.  Part of the nice thing
> with my current Subversion setup is that starting a new project is
> very easy and cheap, I don't create a new repository each time.

Creating the repository for a git project is astonishingly cheap,
because the initial repository exists inside the source tree of the
project itself.  So you don't even have to decide in advance what to
name your project.  I'd say this is even easier than creating a new
svn directory.

You could then decide to publish your project (and go through a couple
of steps to do so) only if it's important enough.  Also, if you use
something like github.com, this part is really easy - and someone else
will pay the bandwidth costs.

> I think what might work with Git (and for which I'd like some advice)
> is something inbetween.  I could have a single Git repository to hold
> my small experiment projects where initially is where I always start
> my work by creating a new directory.  Then if any of them start to
> mature, I could move the project out into it's own repository for
> real.  Would Git support this in some way tracking changes from one
> repo to the other?  Or would I end up having to "replay" all the
> commits from one repo to the other?

Although I definitely recommend just making one git repo per project
in your case, you *could* do exactly what you describe above using
git-subtree:  http://github.com/apenwarr/git-subtree.  Disclosure: I
wrote git-subtree, so I like it by default.

However, doing this would only really be useful if your projects
cross-reference each other in some way.  My main motivation for
writing git-subtree, for example, is that I often end up building
useful tools that grow inside one of my other projects, then turn out
to be good on their own (or as part of another project).  So it's not
that I kept unrelated projects together for convenience (because it
really isn't any more or less convenient in git), but rather that I
wasn't able to predict the future, and git-subtree lets me change my
mind.

Have fun,

Avery