I was trying to determine how close gitolite can come to the ACL model
of a proprietary product called codebeamer, and one of the items was how
to make a "role" (like QA_Lead) have different "members" in different
projects.
I then realised delegation already does that! Which is great, but as I
thought about it more, I realised... well, we'll let the in-code
comments speak for themselves :-)
Anyway, all it needed was a 1-line fix, luckily... <phew> And it would
have only affected people who use delegation.
- all $HOME/blah becomes "$HOME/blah" (bl**dy "Documents and Settings" crap)
- replace bash regex with perl, and in one case replace the check with
something else
- rsync changed to appropriate scp
- since we no longer insist on running from a specific directory, create
tmpgli dir *after* you cd to the right place
msysgit needs this on the initial clone, so it has to be on master. It
doesn't seem to "apply" the gitattributes if you checkout a different branch
later that has that setting; didn't investigate why
You can now add your own hooks into src/hooks/ and they get propagated
along with the update hook that is present there now. Please read the
new section in the admin document, and make sure you understand the
security implications of accidentally fiddling with the "update" script.
This also prompted a major rename spree of all the files to be
consistent, etc. Plus people said that the .sh and .pl suffixes should
be avoided (and I was feeling the same way). I've also been
inconsistent with that "gl-" prefix, so I cleaned that up, and the 00-
and 99- were also funny animals.
Time to get all this cleaned up before we get 1.0 :)
So these are the changes, in case you're looking at just the commit
message and not the diffstat:
src/pta-hook.sh -> src/ga-post-update-hook
src/conf-convert.pl -> src/gl-conf-convert
src/00-easy-install.sh -> src/gl-easy-install
src/99-emergency-addkey.sh -> src/gl-emergency-addkey
src/install.pl -> src/gl-install
src/update-hook.pl -> src/hooks/update
**upgrades no longer touch the config or the keydir**
When you first install gitolite, the easy install script has to do two
*distinct* things:
* install the software
* create and seed the gitolite-admin repo with a minimum config file
and the newly created pubkey
That's fine for an install, because nothing exists yet anyway.
Subsequent invocations of the script should only do the first task (so
that gitolite itself can be upgraded), and not attempt to fiddle with
the config file and pubkeys.
Unfortunately, until now I had not been separating these two activities
cleanly enough. For instance, the commit message for 8e47e01 said:
IMPORTANT: we assume that $admin_name remains the same in an upgrade
-- that's how we detect it is an upgrade! Change that name or his
pubkey, and you're toast!
Ouch!
So now I decided to clean things up. The "Usage" message tells you
clearly what to do for an upgrade.
Should have been like this from the beginning, but hey we got there
eventually :)
----
Code-wise, this is a major refactor of the easy install script. It uses
an old forgotten trick to get forward refs for bash functions ;-) and in
the process cleans up the flow quite a bit.
- "it's an upgrade" is decided by presence of gitolite.conf (not a pubkey)
- admin_name optional (and will be ignored if given) for upgrades
plus a lot of comments and some minor text changes
Packaging gitolite for debian requires the rc file to be in /etc/gitolite.
But non-root installs must still be supported, and they need it in $HOME.
This means the rc file is no longer in a fixed place, which needs code to find
the rc file first. See comments inside new file 'gitolite.pm' for details.
The rest of the changes are in the other programs, to replace the hard-coded
rc filename with a call to this new code.
- README: add a "what" section first, plus a few minor fixes
- doc/5:
- remove reference to obsolete ml branch URL; point it to the right
place with the right section name
- change text to reflect the fact that p-t-a is now the default!
- example config file is now all comments (should have been that way anyway)
- we detect if it is an upgrade and act accordingly (see below)
IMPORTANT: we assume that $admin_name remains the same in an upgrade -- that's
how we detect it is an upgrade! Change that name or his pubkey, and you're
toast!
