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

[James Youngman]

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{import-gnulib.sh} depended on
@code{cvs update -D}, which at the time @code{git-cvspserver} did not
support.

> I think the import-gnulib.sh 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{import-gnulib.sh} 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{import-gnulib.sh} generates.  However, you can make a normal
(full) clone with @code{git clone
git_repo="git://git.savannah.gnu.org/gnulib.git"}.  Do this somewhere
outside the findutils source tree.

I added a comment to import-gnulib.sh 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/

Thanks.

James.