git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Herland <johan@herland.net>
To: git@vger.kernel.org
Cc: Reece Dunn <msclrhd@googlemail.com>
Subject: Re: git clone questions relating to cpio
Date: Mon, 01 Oct 2007 23:42:36 +0200	[thread overview]
Message-ID: <200710012342.37352.johan@herland.net> (raw)
In-Reply-To: <3f4fd2640710011228w61ce34b5ve47ea529eed384fd@mail.gmail.com>

On Monday 01 October 2007, Reece Dunn wrote:
> Hi,
> 
> I am running a Linux From Scratch 6.2 system that does not have cpio
> installed on it. This means that I can't clone a local repository
> unless I install cpio. Is it possible to use a fallback method if cpio
> is not present, as there is no NO_CPIO option on make like there is
> for OpenSSH, cURL and expat?

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

> Also, I have an external USB hardrive that is mounted onto the virtual
> filesystem. Will clones from the USB harddrive (or a USB flash drive
> that is mounted) result in a copy being performed, not a hardlink?

Hardlinks are impossible across filesystems. If you're cloning to a 
different filesystem git will _have_ to make a full copy.

> Ideally, the hard linking for local clones should be optional.

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

> What if I want to move a repository because, for example, I have imported
> a CVS repository and now want to push it to a new bare repository?

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

  reply	other threads:[~2007-10-01 21:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-01 19:28 git clone questions relating to cpio Reece Dunn
2007-10-01 21:42 ` Johan Herland [this message]
2007-10-02 21:09   ` Reece Dunn
2007-10-02 23:42     ` [PATCH] Mention 'cpio' dependency in INSTALL Johan Herland
2007-10-03  0:14       ` Junio C Hamano
2007-10-03  6:09         ` Chris Larson
2007-10-03  7:40         ` Miklos Vajna
2007-10-03  8:27           ` [PATCH v2] INSTALL: Update section on external dependencies Johan Herland
2007-10-03 15:56             ` Johannes Schindelin
2007-10-03 16:05               ` Shawn O. Pearce
2007-10-01 23:23 ` git clone questions relating to cpio Johannes Schindelin
2007-10-01 23:32   ` Junio C Hamano
2007-10-02  6:11     ` Johannes Sixt
2007-10-02  6:23       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200710012342.37352.johan@herland.net \
    --to=johan@herland.net \
    --cc=git@vger.kernel.org \
    --cc=msclrhd@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).