[Top][All Lists]

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

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

From: Thien-Thi Nguyen
Subject: Re: [PATCH] Update doc "UPDATED" machinery.
Date: Thu, 03 Jul 2008 11:25:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

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

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

I've done a little experimentation (using git 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 \

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.


reply via email to

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