On Nov 28, 2007 1:31 AM, Eric Blake <[EMAIL PROTECTED]> 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.
_______________________________________________
Findutils-patches mailing list
Findutils-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/findutils-patches
