Re: [PATCH] Update doc "UPDATED" machinery.

[Thien-Thi Nguyen]

() Simon Josefsson <address@hidden>
() Thu, 19 Jun 2008 12:51:14 +0200

   > [low-cost "fork of gnulib" publishing]

   You could push your fork to some git host like repo.or.cz, or
   setup gitweb on your own site, although it doesn't strike me as
   ideal (what if everyone creates their own gnulib fork on
   repo.or.cz?).

If they use "git clone -s -l" internally, it's probably No Big Deal.

I've done a little experimentation (using git 1.5.3.5) and i think
what i seek is partially achievable: "normal" disk space cost, low
bandwidth cost w/ third party cooperation (not guaranteed).

On my side, i would publish like so:

 cd ~/build/GNU/gnulib
 git prune
 git gc --prune
 git clone -l --bare .git $(pubrepo)      # initially
 git push -v --tags $(pubrepo) $(branch)  # subsequently

Then, $(pubrepo) is staged to my (humble) web host at some point.
For j.r.gnulib-hacker, i would request that they do this:

 cd $(local)/..
 git clone -l --reference $(local) \
   http://www.gnuvola.org/wip/gnulib.git \
   ttn-gnulib

where $(local) is the local gnulib repo.  This would create a new dir
ttn-gnulib/, a sibling of $(local), that shares storage w/ $(local)
objects, therefore reducing network load on gnuvola.org for clone/pull.

As you can see, if the "--reference $(local)" is omitted, this
devolves into a normal clone operation.

There is also a tantalizing blurb about "http-alternates" in
the Documentation/repository-layout.txt, but i haven't investigated.

thi