I would actually suggest against that. Why? Because it will set a new
"origin" (pointing to your old repo), and if you had something else
before, that's probably not what you want.
Anyway, for the *shared* repositories, the git-1.5 changes really don't
tend to make any difference anyway (since they don't even tend to really
_care_ about things like origin branches - they are just used to push and
pull from).
It's much more noticeable for the actual *development* repositories,
because they are the ones that have "origin" pointing to something else.
And yes, for those development repositories, it's usually a good idea to
just do
mv project old-project
git clone /repos/git/project
cd project
.. work work work ..
and be happy.
You can also set up the new configurations by hand in an old repository,
but there really doesn't tend to be a lot of reason to do that. Just as an
example: the above was _literally_ what I did myself, just because I was
too lazy to start editing .git/config files and setting things up in other
ways (renaming origin branches etc).
In fact, I just did it the other day for my "sparse" repository (which is
another project I started, but that is maintained by others these days).
So here's a snippet from my bash history:
(that "cat old-sparse/.git/config" was just because I had forgotten
exactly where the origin of that repo was, so I did that cat just to do a
cut-and-paste for the subsequent "git clone" ;^).
And yes, I did that just to get the nicer branch layout, something that my
old sparse git repo didn't have, because I had set it up with an old
version of git (and done some minimal manual maintenance).
