Bill Lear wrote:
> On Thursday, February 8, 2007 at 18:33:24 (-0500) Shawn O. Pearce writes:
>> Bill Lear <rael@xxxxxxxxxx> wrote:
>>>
>>> With regard to the new version and old repos, am I correct in assuming
>>> that we can upgrade our old repo (a bare one) to the new git by first
>>> installing the new git, and then doing this:
>>>
>>> % cd /repos/git
>>> % mv project project.old_git
>>> % git --bare clone project.old_git project
>>>
>>> or is there something else we must do?
>>
>> In the case of a bare repo, there isn't anything to do.
>
> So, I assume I need to tell our developers that once we have installed
> the new git, they will need to set aside their old repos and just
> clone again from our company repo?
Nope.
1. New git works with old repositories, and would continue to work.
Nevertheless you need new layout and new configuration to make use
of some new features.
2. They need to clone _their own_ repositories. It's the simplest
way, but
3. You can simply
a) convert remotes configuration from .git/remotes/origin file
to .git/config using remotes2config.sh script in contrib area
of git, or http://repo.or.cz/w/git.git?a=blob_plain;f=contrib/remotes2config.sh
b) hand edit remotes configuration to use globbing for refspec,
and per branch configuration
If old repository was _not_ cloned with --use-separate-remote (using
separate remote layout), you would also have to:
c) move branches from old layout to new layout using "git branch -m"
command: 'refs/heads/origin' branch to 'refs/remotes/origin/master',
all branches except 'master' (refs/heads/master) from
'refs/heads/<branch>' to 'refs/remotes/origin/<branch>'.
That's all. You have new layout and new configuration without re-cloning.
--
Jakub Narebski
Poland
-
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