Using "file://" when specifying the source repo will force git-clone to use
the git protocol, instead of doing a copy/hardlink.
I.e. change "git clone foo bar" to "git clone file://foo bar" in order to
prevent git-clone from calling cpio.
However, grepping for cpio in the git source tree reveals a couple of uses
in git-merge, so you might bump into problems there...
Hardlinks are impossible across filesystems. If you're cloning to a
different filesystem git will _have_ to make a full copy.
<quote src="git-clone(1)">
--local, -l
When the repository to clone from is on a local machine, this flag
bypasses normal "git aware" transport mechanism and clones the repository
by making a copy of HEAD and everything under objects and refs directories.
The files under .git/objects/ directory are hardlinked to save space when
possible. This is now the default when the source repository is specified
with /path/to/repo syntax, so it essentially is a no-op option. To force
copying instead of hardlinking (which may be desirable if you are trying to
make a back-up of your repository), but still avoid the usual "git aware"
transport mechanism, --no-hardlinks can be used.
--no-hardlinks
Optimize the cloning process from a repository on a local filesystem by
copying files under .git/objects directory.
</quote>
And as I said above, you can use "file://" to force the "git aware"
transport mechanism, which bypasses the whole local copy/hardlink issue
entirely.
Even if you were to use hardlinks, cloning a repo followed by deleting the
original will be safe (as long as you don't supply '--shared' to
git-clone). That's the beauty of hardlinks.
I also think it's fairly safe to just 'mv' the whole repository to its new
location.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
-
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