Bill Lear wrote:

quoted text
> On Thursday, February 8, 2007 at 18:33:24 (-0500) Shawn O. Pearce writes:

>> Bill Lear  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/' to 'refs/remotes/origin/'.
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@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html