I just cloned the latest git and it builds ok, but fails when I clone:
% uname -a

Linux gronk.zopyra.com 2.4.9-21 #1 Thu Jan 17 14:16:30 EST 2002 i686 unknown
% git --version

git version gitgui.0.8.4.g9c514
% git clone --bare ~/my_repo

Initialized empty Git repository in /repos/git/my_repo/

/opt/git/bin/git-clone: line 297: cpio: command not found
So, should git not check this when it is building?  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...
Bill

-

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).
To work around this, specify the repository location with file://, and

git won't try to hardlink (and hence won't try to use cpio).
--

Karl Hasselström, kha@treskal.com

      www.treskal.com/kalle

-

Why cpio? What is wrong with ln(1) (every Unix should have one) or

link(2) ?
Erik
--=20

They're all fools. Don't worry. Darwin may be slow, but he'll

eventually get them. -- Matthew Lammers in alt.sysadmin.recovery

Since git-clone is not yet a builtin, and is actually a shell script, it

makes more sense to use cpio than ln.
Mike

-

Hi,
Patch, please?
Ciao,

Dscho
-

Here you go.
Remove dependency on cpio for git-clone. Apparently some POSIX systems

out there don't have cpio, just assume cp is there.
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.

=20

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

=20

  - 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

 	;;
--=20

They're all fools. Don't worry. Darwin may be slow, but he'll

eventually get them. -- Matthew Lammers in alt.sysadmin.recovery

cp -l isn't even close to portable. It's not in POSIX, and doesn't work

on (at least) Solaris.
I think Mike's patch (cpio if available, copy otherwise) is a reasonable

approach. If there are other methods (and I think cp -l is not

unreasonable for systems where it is supported and cpio is unavailable),

then perhaps it is worth trying them one by one and dropping back to

full copy if all fail.
-Peff

-

Hmm, thanks for the workaround, but I don't altogether like leaving

things like this.
If the system does not have cpio, I think the build of git should

complain and fail, or it should activate code that treats any

repository accessed over the file system as it would file://.
No sense in leaving this surprise to the user so late in the cycle.
Bill

-

git may be build and run on two different hosts, so while the build-time

check is good there should be a run-time check as well.
/Allan

-

Something like this could be done at run-time instead. You might

install cpio, but shouldn't require a rebuild of git just to use it.
Dave.

-