() Simon Josefsson <[EMAIL PROTECTED]> () 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
