- install.sh is now install.pl (had to happen sooner or later!)
- now handles updates more gracefully, doesn't overwrite important stuff :)
- makes the install sequence much easier to understand
(just run it and follow the prompts!)
- made ~/.gitolite.rc much clearer to edit
- install is even clearer now (I hope!), esp to people with root
access who seem to expect something else :)
- used path vars (from ~/.gitolite.rc) more consistently, and
- added refeerences to ~/.gitolite.rc for resolving them
In the "create new repos" loop, we need an absolute value for REPO_BASE, in
order to be able to chdir back and forth. But (taking the "normal user with
no privileges" assumption too far!) we assumed REPO_BASE would be within
$HOME, and relative to it. So it fails when someone wants the repo_base
elsewhere.
Now we don't prefix $HOME if REPO_BASE is already absolute (begins with a "/")
bug reported by evocallaghan
I had to make two minor fixes while migrating my work repos:
1. I forgot to honor '@all'; oops!
While I was about it, I also fixed the "access denied"
message to show what rights were being tried when it
failed.
2. I forgot that URLs can have leading slashes (I myself
only use URLs like gs:reponame.git, where gs is an ssh
stanza that describes the git server in question).
Ilari pointed out that in case of branch deletion the *new* SHA could be 0,
which causes an ugly
fatal: Not a valid commit name 0000000000000000000000000000000000000000
Since we consider deletion an extreme form of rewind, the end result does not
change ($merge_base will be unequal to $oldsha anyway), but we do need to
squelch the ugly message.
- factored out all the pathnames etc to an rc
- taught it to create repos that dont exist but are mentioned
- promoted user up one level (moving ref down) because gl-auth needs it
- REPO_BASE no longer contains $HOME so that has to be added in manually
- little bugs here and there, like in @refs
