My problem is that for unrelated scripts, the git model suggests to me that each script would have its own git repository. Although this is obviously possible, I wonder how managable this would be in practice.

(emphasis by me). Suggestions are just generally good ideas; it doesn't mean that you have to follow them, if they don't apply in your case.

I often had the situation of having a repository with various stuff. Over time some of the scripts grew into larger projects, so I extracted them (and their history) into a separate repository, and deleted them in the original repo, leaving a note on where to find the files now.

More repositories imply more administration overhead, so I only go the route of more repositories when I see a real benefit from it.

With git, the main thing to consider when creating a repository is "who is going to use it". Obviously, when for script x, you are collaborating with A, B, and C, and for script y, you are collaborating with D, and E, it makes more sense to have multiple repositories than if A, B, C, D, and E all work on x and y.

If it's just a bunch of scripts that live in your ~/bin, it doesn't make a whole lot of sense to have separate repositories for each. But I'd create different repositories for /opt/whatever/make-the-world and /usr/local/bin/silly.

I mean, for small things and finished projects, how often do you really need the version history? In git it's just this .git folder in your project directory. I didn't experience an administration overhead since my switch.

Just running git init to create a local repository is obviously not such a big deal. However, if I want to collaborate with my colleagues, I have to set up a corresponding bare repository on a server that I can then push to. Doing this for a couple of dozen individual scripts seems like it might be unmanagable overkill.

Regarding the history, I do want this for individual files and I don't have such things as "finished" projects. I mainly have stuff for myself, which either contains bugs or is not as good as it could be, or both.

Perhaps I just need to try working with a small number of repositories and see how it feels. I gather that can always merge them at some later point.

Cheers,

loris

As I said, I didn't experience an overhead. In SVN, you normally need one step to prepare the directory for SVN import (e.g. the trunk/ branch/ merge directory structure) which somehow would correspond to git init. To publish it, svn import would correspond to git clone -bare.

Your couple of dozen scripts are all unrelated? So there is no group of scripts your colleagues would likely want to fetch together?

What I meant with my history comment was, I also used to have a single big SVN repository for almost everything. My SVN dump was huge at the end. But for most projects, I never actually needed the history later on. Now I have a decent backup system and git when version control is actually needed (collaboration, branching etc.). So much cleaner and better...

I will be following this string due a personal interest as well. It sounds like what you are looking for is joining of a Content Management System combined with a Version Control System that supports software development. (I am assuming that http://github.com/ didn't meet your needs)

Non Software industries have systems like this for general product life-cycle management. However they are very hardware development and document driven. They stumble substantially when doing version control for software development. That doesn't even mention the large per seat fee associated with the proprietary nature of these packages.

I also ask what are the available options?