threads / discuss / 10538

cpio command not found

Subject: cpio command not found

## tl;dr

10 messages between Oct 31, 2007 and Oct 31, 2007.

replies: 9people: 8as markdown or json

Bill Lear· Oct 31, 2007, 12:51 UTC · lore

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

Karl Hasselström· Oct 31, 2007, 13:30 UTC · re: Bill Lear · lore

Re: cpio command not found

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

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

Bill Lear· Oct 31, 2007, 13:54 UTC · re: Karl Hasselström · lore

Re: cpio command not found

On Wednesday, October 31, 2007 at 14:30:39 (+0100) Karl Hasselström writes:

Show 12 quoted lines

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

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

Allan Wind· Oct 31, 2007, 13:58 UTC · re: Bill Lear · lore

Re: cpio command not found

On 2007-10-31T07:54:02-0600, Bill Lear wrote:

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

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

David Symonds· Oct 31, 2007, 14:00 UTC · re: Bill Lear · lore

Re: cpio command not found

On 11/1/07, Bill Lear <rael@zopyra.com> wrote:

Show 20 quoted lines

> On Wednesday, October 31, 2007 at 14:30:39 (+0100) Karl Hasselström writes:
> >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).
> >
> >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).
>
> 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://.

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.

Erik Mouw· Oct 31, 2007, 14:06 UTC · re: Karl Hasselström · lore

Re: cpio command not found

On Wed, Oct 31, 2007 at 02:30:39PM +0100, Karl Hasselstr?m wrote:

Show 9 quoted lines

> 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) ?

Erik

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

Johannes Schindelin· Oct 31, 2007, 14:20 UTC · re: Erik Mouw · lore

Re: cpio command not found

Hi,

On Wed, 31 Oct 2007, Erik Mouw wrote:

Show 13 quoted lines

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

Ciao, Dscho

Erik Mouw· Oct 31, 2007, 20:14 UTC · re: Johannes Schindelin · lore

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

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

Show 17 quoted lines

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

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

Jeff King· Oct 31, 2007, 20:22 UTC · re: Erik Mouw · lore

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

On Wed, Oct 31, 2007 at 09:14:25PM +0100, Erik Mouw wrote:

> > Patch, please?
> 
> Here you go.

Good, now we have something to critique. :)

> -		find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
> +		cp -Rp$l objects/ "$GIT_DIR/" || exit 1

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

Mike Hommey· Oct 31, 2007, 19:48 UTC · re: Erik Mouw · lore

Re: cpio command not found

On Wed, Oct 31, 2007 at 03:06:55PM +0100, Erik Mouw wrote:

Show 13 quoted lines

> 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) ?

Since git-clone is not yet a builtin, and is actually a shell script, it makes more sense to use cpio than ln.

Mike