[PATCH] Get rid of cpio in git-clone (was: Re: cpio command not found)

From

EMErik Mouw <mouw@nl.linux.org>

Date

Oct 31, 2007, 20:14 UTC

Message-ID

<20071031201425.GA29332@gateway.home>

In-Reply-To

<Pine.LNX.4.64.0710311420330.4362@racer.site>

On Wed, Oct 31, 2007 at 02:20:47PM +0000, Johannes Schindelin wrote:

> On Wed, 31 Oct 2007, Erik Mouw wrote:
> 
> > On Wed, Oct 31, 2007 at 02:30:39PM +0100, Karl Hasselstr?m wrote:
> > > On 2007-10-31 06:51:30 -0600, Bill Lear wrote:
> > > 
> > > > I don't remember this dependence from earlier versions of git. I 
> > > > have been running git 1.4.xx on this machine for a while...
> > > 
> > > When you clone with -l, git uses cpio to hardlink to the original 
> > > repository. What has changed is that -l is now used by default when 
> > > cloning a repository that's accessed via the file system (as opposed 
> > > to over some network protocol).
> > 
> > Why cpio? What is wrong with ln(1) (every Unix should have one) or
> > link(2) ?
> 
> Patch, please?

Here you go.

Signed-off-by: Erik Mouw <mouw@nl.linux.org>

diff --git a/INSTALL b/INSTALL
index f1eb404..9074563 100644
--- a/INSTALL
+++ b/INSTALL
@@ -79,8 +79,7 @@ Issues of note:
 	- "perl" and POSIX-compliant shells are needed to use most of
 	  the barebone Porcelainish scripts.
 
-	- "cpio" is used by git-merge for saving and restoring the index,
-	  and by git-clone when doing a local (possibly hardlinked) clone.
+	- "cpio" is used by git-merge for saving and restoring the index.
 
  - Some platform specific issues are dealt with Makefile rules,
    but depending on your specific installation, you may not
diff --git a/git-clone.sh b/git-clone.sh
index 0ea3c24..061534c 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -294,7 +294,7 @@ yes)
 			fi
 		fi &&
 		cd "$repo" &&
-		find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
+		cp -Rp$l objects/ "$GIT_DIR/" || exit 1
 	fi
 	git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" || exit 1
 	;;

-- 
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery