[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
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH] Update doc "UPDATED" machinery.,
Thien-Thi Nguyen <=