[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Findutils-patches] [PATCH] Check gnulib out with git rather than CV

From: James Youngman
Subject: Re: [Findutils-patches] [PATCH] Check gnulib out with git rather than CVS.
Date: Thu, 29 Nov 2007 11:05:57 +0000

On Nov 28, 2007 1:31 AM, Eric Blake <address@hidden> wrote:
> git might fix this in the future.  How about s/lacks working support/\$ as
> of this writing/, to add some future-proofing?

I rephrased like this:

Gnulib does not have a release process which results in a source
tarball you can download.  Instead, the code is simply made available
by GIT.   The code is also available via @code{git-cvspserver}, but
we decided not to use this, since @code{} depended on
@code{cvs update -D}, which at the time @code{git-cvspserver} did not

> I think the should probably use a shallow clone to cut
> down on network bandwidth usage; but that means that cloning the
> gnulib-git directory into an external git directory won't work.  So maybe
> this paragraph should be revisited.

I rephrased that paragraph to provide instructions which should still
work if we switch to a shallow clone, but have (yet) actually switched
to a shallow clone:

@item Check out a copy of the Gnulib source
Check out a copy of the Gnulib source tree.  The
@code{} script may have generated a shallow git clone
as opposed to a normal, full clone in the directory @file{gnulib-git}.
This means that you may not be able to clone the repository that
@code{} generates.  However, you can make a normal
(full) clone with @code{git clone
git_repo="git://"}.  Do this somewhere
outside the findutils source tree.

I added a comment to to indicate that in the future
maybe we should use a shallow clone.

> I'm wondering if git rev-parse HEAD is better here.

Thanks, I didn't know about that.

> s/checkjed/checked/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]