I use SVN and have a single repository with all sorts of stuff in
it, varying from LaTeX files to applications in Perl and individual
Perl scripts. However, I have been looking at git, mainly because of
the advantages of it being a distributed system.

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.

How unrelated are they? Are they all made for different customers? Do they live in different directories? Are they all used for different projects? Are they all shared between different sets of people?

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.

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.

One of the things I like about git is that it is easy and fast to set up a local repository. You have a small script and decide it would be nice to try a couple of things. Then just run git init and you have your local version control in your script directory. If you later want to collaborate, it's easy to clone the repository wherever you want. If you add the script to your one big SVN repository, it's there forever.

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.

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...

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.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other