2012-01-04 03:32 Sitaram Chamarty <sitar...@gmail.com> (Upstream):
| 644648 -- upstream won't fix. You may choose to do what you wish in
| debian :-) It's a conf file. Conf files do sometimes break on a
| major version upgrade and need to be fixedup.
It would be good if program did some Lint checks after reading
~/.gitolite.rc.
If variable GL_PACKAGE_CONF is not set (it is by default) then
write error messages telling that program has probably been
upgraded to a newer version and suggest actions what to do next
(point to web page for upgrade notes?)
End If
But a more sustainable approach is this: Support TWO configuration files.
A, the default supplied by the gitolite itself. This may chnage from
upgrade to upgrade.
B, read *after* A (which contains defaults). This is where user's can
store their private/modified settings.
An example. Reserve separate directory for configuration:
~/.gitolite/00base (A)
~/.gitolite/10local (AB)
Program reads all files under ~/.gitolite/ directory, in sorted order.
It reads A first, then B. A set's basic value. B can override
them. Ot any successive other file.
The installation ships with A, user is instructed in comments of A to
"not touch" this file, but copy it under B to make personal chnages.
No Upgrade problems, No conflicts. No missing variables as stock A is
always read.
Using separate directory makes it possible to put files nder version
control. The current ~/.gitolite.rc being at top of HOME cannot.
Jari
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
