also
- new "WEB_INTERFACE" variable (defaults to 'gitweb')
- setup_web_access (write a plain list of repos out)
- add_del_web_access (add/delete a single repo from projects.list)
The backward compat breakage is for people who already have all kinds of
arbitrary characters in filenames *and* use `NAME/` rules. See the doc
change in this commit for details and mitigation. See this link for
background:
http://groups.google.com/group/gitolite/browse_thread/thread/8dc5242052b16d0f
Thanks to Dan Carpenter for the audit.
major changes
- (src) one error message got more detail
- long overdue fixup to developer notes doc
plus many minor changes that have been piling up
PS: to dig into the "alliterative animal" comment, check the channel
logs around aug 23rd ;-)
comments from contributor via email:
* Translates all repos from gitosis to gitolite, even if their are not
associated with any groups
* Transfers gitweb settings (gitweb, description and owner)
* Transfers git-dameon settings
* Maintains comments for groups and repos
As far as I can tell, the results from this filter are working fine
for our transfer from gitosis to gitolite.
wrap_print() was written to create a new file and rename the old one to
avoid a partially written file being read by other processes. This has
only been reported for the 'projects.list' file, but I just did it for
all files as a matter of course.
list of files currently written via this function:
gl-creater, gl-perms, description, git-daemon-export-ok, projects.list
However, some people want to do the following:
- set REPO_UMASK tight (0077, default)
- manually change the perms to something looser (typically g+rX) for
specific repos
- set core.sharedRepository to 0750 (git is documented to honor that
config if available and to override umask)
Except that core.sharedRepository does not apply to files written by
gitolite and not git itself. So they would open up their description
files and the next compile would close them again!
This patch prevents this from happening. If the file already exists, it
maintains the same permissions after the rename.
previously, these two would produce different results
config aa.bb = 'true' # config file line includes single quotes
config aa.bb = "true" # config file line does not include any quotes
Now the former will also behave like the latter.
Without this, complex mirroring scenarios will be unpredictable. For
example (abbreviating "gitolite.mirror." to "gimo.") something as simple
as this will not give "foo" his different mirror setup
repo @all
config gimo.master = "frodo"
config gimo.slaves = "sam"
repo foo
config gimo.master = "sam"
config gimo.slaves = "frodo gollum"
repo foo bar
RW = u1
Even worse things happen when you have wild cards.
Now, however, they all come in the right sequence and the most recent
one takes effect (unlike ACL rules, where the first match wins, because
there you're trying to just find a match and get out, while here you're
just mindlessly applying config lines in the right order).
We previously said all mirroring features are disabled if GL_HOSTNAME is
not set.
But what if, after mirroring has been setup, and master/slaves defined
for a repo, a slave admin fat-fingers the RC file and accidentally
comments out GL_HOSTNAME? We might end up violating RULE NUMBER ONE!
- post-receive now just calls mirror-push
- mirror-push is a medium complex shell script (all that backgrounding
etc., can't be done so easily in God's first language!)
- mirror-shell is now a perl program that does a few different things
(receive mirror-pushes, command line re-sync, re-sync requests from a
slave, etc)
- auth-command changes to reject/redirect non-native pushes
Supporting git on DOS may be a fact of life, but it felt good to make
them use the "right" editor (hint: starts with v, ends with m, has three
letters), or at least something equivalent, to produce their setperms
input files.
I'd say "yes Fred I know. However, Unix doesn't work like that, and
when talking to a big, important, OS like Unix from your little
single-user workstation, you do have to go the extra mile. It's not
that different from going into a meeting with the CEO you know -- you
dress up a little for that meeting don't you?". And Fred would nod, a
little awed by the analogy. Maybe the awe was tinged with a wee bit of
anger but not much; he knows there's a hierarchy among OSs, just like
among people, and he knows where his OS stands in that hierarchy...
----
For the humour impaired, that was a joke. To start with, I don't know
anyone called Fred.
It *is* true that I tend to ignore DOS if at all possible, especially in
my *code*. But since I don't really use wildrepos at work, this issue
would never have come up for me, even in the DOS projects I manage.
In this case someone who's contributed a heck of a lot to the evolution
of gitolite asked, so here it is.
----
oh and in case you were wondering, DOS stands for "dominant operating
system" ;-)
Fix a problem with authkeys perms when REPO_UMASK is too loose.
(To duplicate it, run a fresh, non-root install, and when gl-setup pops
up an editor, change the REPO_UMASK to 0007 (from the default 0077).
You'll find that ~/.ssh/authorized_keys now has g+w set, causing sshd to
refuse key-based access.)
And before you ask, even though gl-setup does it, I won't fiddle with
the permissions of an existing file in *this* code. (gl-setup is run
manually by the admin, this one gets run on every push).
----
Side note: 9ad7ea4 was somewhat forced on me, and I didn't really agree
with parts of it. I have no idea why I gave in so easily, but it won't
happen again!
a warn/die may happen even before setup_environment() has been called,
so then log_it() tries to use uninitialised variables and it then adds
to the confusion complaining about *those*
make the arguments optional (with documented defaults) plus they need
not exist a priori, reducing one command (the silly mkdir!) that the
user has to run.
All this is preparatory to deprecating the from-client method. We've
even switched the test suite to 'non-root' method now
The KDE folks have a projects.list file that gets picked up by rsync and
sent elsewhere in some cron-ish manner. They noticed that occasionally
the file that went across was truncated, which indicates that maybe it
got picked up while it was still being written.
oh and this change also affects any files that get written using
wrap_print()
(thanks to yoonique dot net at gmail; he also tested that files with
some normal and some md5 passwords, such as would happen on an upgrade,
work fine)
git 1.7.4+ insists on these two being defined. So I reduce my support
load by forcing them if they were not set.
Much easier than explaining to people what should be obvious from the
error message.
