To segregate the historical commits (can't remember why),
I originally placed their pack in an alternate object store,
but later I found that a *.keep file does the job as well.
This gives a considerable speedup in git gc. It takes some
more disk space but OTOH you might then run gc more often
and have fewer loose objects.
real user sys (tested in this order)
1m15.900s 0m59.732s 0m4.336s gc after clone&graft without *.keep
0m23.162s 0m17.549s 0m1.588s gc after clone&graft with *.keep
0m06.932s 0m04.440s 0m0.588s gc after clone&graft&gc with *.keep
0m32.214s 0m24.138s 0m2.284s gc after clone&graft&gc without *.keep
Total size of .git/objects/pack/ was 90592 KiB without *.keep
and 97397 KiB with *.keep. So *.keep reduced gc time by 70-80%
but increased disk space usage by 7.5%.
The fully dashed form git-update-server-info is deprecated
in Git 1.5.4 and will cease to work in Git 1.6.0 (unless
PATH is modified). Use git update-server-info instead.
* All arguments must now be given as options.
* Documented.
* chmod +x in Git.
* Do not distribute files whose contents should depend on what the
configure script found: config.h, config.log, config.status,
features.log, Makefile.config, contrib/conv/w3m2links.awk,
contrib/lua/hooks.lua, doc/man/man1/elinks.1.
* Do not distribute other files that configure will rebuild anyway:
src/intl/gettext/ref-add.sed, src/intl/gettext/ref-del.sed.
But do distribute contrib/elinks.spec, because it specifies how
to run configure, and only the @VERSION@ varies in it.
* Do not distribute the empty directory po/.deps.
* Save the commit ID into .git/HEAD in the tar file.
* Compress the *.tar.gz and *.tar.bz2 from the same *.tar file.
* Instead of *.tar.gz.md5 and *.tar.bz2.md5, generate a *.md5 file
that contains md5sums for *.tar, *.tar.gz, and *.tar.bz2.
* Use md5sum --binary for the sake of Windows.
The history converted from CVS is not in repo.or.cz though, so keep
referring to pasky.or.cz for that. (We don't seem to use
"gitweb.elinks.cz", which is a DNS alias for pasky.or.cz.)
<paakku> Do you think we should maybe point people to gitweb at
repo.or.cz rather than pasky.or.cz?
<pasky> absolutely
<pasky> actually I thought we already are pointing people at
repo.or.cz
<pasky> at least there was some movement to do that already, I believe
:)
I don't think there is any point in keeping this file when users can
easily run elinks -no-home -config-dump to get an equivalent one.
The result won't include options for features that were disabled at
configure time, but the users won't need those options either.
Furthermore, if this file is installed as /etc/elinks/elinks.conf like
contrib/debian/rules does, and people then modify it, they cannot
easily upgrade to changed defaults in later ELinks versions; these
changes may even be security-related, like ecmascript.enable in the
upcoming ELinks 0.12.0. It is better if /etc/elinks/elinks.conf
contains only the settings that the sysadmin explicitly wants to
change from the defaults, and all the rest comes from the elinks
binary.
This is the mkdist to which doc/release.txt refers.
The script was originally written by Pasky and then modified by Fonseca.
This version doesn't know the correct directory names and so won't work
without modifications, but it seems better to check it in now than wait.
Files in the debian directory aren't being kept up to date.
(For example, debian/control declares a dependency on libgnutls11-dev
even though ELinks now requires at least 1.2, and debian/changelog
does not mention the 0.11.* releases.)
Until the files are up to date again and there is a commitment to keep
them so, they belong in contrib.
Document what happens if goto_url_hook or follow_url_hook returns None or "".
doc/events.txt already explains the corresponding C values.
[ commit message by me --KON ]
On Dec 31, 2006, at 11:30am, Kalle Olavi Niemitalo writes:
>src/scripting/python/hooks.c (script_hook_url) calls hooks as
>goto_url_hook(new-url, current-url) and follow_url_hook(new-url).
>It has a comment saying that the current-url parameter exists
>only for compatibility and that the script can instead use
>elinks.current_url(). However, the current-url parameter was
>added in commit 87e27b9b3e and is
>not in ELinks 0.11.2, so any compatibility problems would only
>hit people who have been using 0.12.GIT snapshots. Can we remove
>the second parameter now before releasing ELinks 0.12pre1?
The decision isn't up to me, but I think this is a good idea. Here's a
patch that would update the documentation and hooks.py, as well as hooks.c.
FYI, if this patch is applied then anyone who's still trying to use a
goto_url_hook that expects a second argument will get a "Browser scripting
error" dialog box that says:
An error occurred while running a Python script:
TypeError: goto_url_hook() takes exactly 2 arguments (1 given)
Before this patch, init_python would crash trying to set up elinks.home
at the Python side. Now it uses None as the value in that case.
Also, init_python no longer adds "(null)" to $PYTHONPATH.
