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" ;-)
otherwise repo names containing "@" in them were causing the @foo part
to be interpolated (as empty of course) instead of being taken literally
reported by silvio dot fricke at googlemail
(and in one other place it needs to be defined earlier)
I never caught this because in my testing those error conditions --
caused by lack of afc3a06 -- never came up.
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*
I'd originally written some minimal documentation for this ADC, but I
liked Jeff's version so much that I borrowed it, added the final section
("important notes for the admin"), made a few other minor fixups, and
then happily ditched my version.
(the ones that require GL_BYPASS_UPDATE_HOOK to be set are done slightly
differently because I just didn't want all the hassle of saving and
restoring that variable on the perl side)
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)
Initial entry of markdown documentation as generated by pod2markdown.
Note addition of table-of-contents and appropriate anchors
Signed-off-by: Christopher M. Fuhrman <cfuhrman@panix.com>
[some formatting type changes done by Sitaram]
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.
The need for this comes about as follows:
- a project may allow its developers "RWC" (or "RW+C") so that they
can create feature branches when needed. Note that these are
*feature* branches, so they can't use the "personal branches"
mechanism that gitolite already has.
- the developers are *not* given RWCD (or RW+CD) to prevent accidental
deletion of an important branch. Branch *deletion* is something
that only a few trusted admins can do.
- as a result, there are sometimes situations where a developer
creates a misnamed branch and then has to ask the admins to help get
rid of it.
What the KDE folks wanted was a way to allow the creator of a branch to
be able to delete it. In addition, they needed this allowed only for a
fixed duration after the creation of a branch, not forever (for the same
reason they don't get RWCD, to prevent accidents).
These are my reasons why this feature is implemented as an ADC instead
of being "in core":
- we'd need additional syntax to differentiate this special case
(which is sort of in between RWC and RWCD, if you think about it).
I'm reluctant to complicate the syntax further for something that is
only occasionally needed.
- we'd need either (a) code to parse the log files, or, (b) code to
maintain "who created this ref" on every push that creates a ref.
- parsing the log files is too kludgy and inelegant to be in core,
not to mention potentially very slow for really large projects
- code to maintain the a history of "who created this ref" is too
cumbersome, especially because of the need to expire old entries
after a time.
the first one is commented clearly enough, the second one is a pure bug
(though it wouldn't have affected anything except for the ultra-paranoid
"fsckObjects" config var not being set; no biggie...)
$ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as
$REPO_BASE, except it is meant to be passed to hooks, ADCs and other
child programs. And since you can't be sure where the child program
starts in, this became an absolute path.
Gradually, however, I started using it wherever I needed an absolute
path (mostly in code that jumps around various directories to do stuff).
Which is silly, because there's no reason $REPO_BASE cannot also be made
an absolute, even if the rc file has a relative path.
So that's what I did now: made $REPO_BASE absolute very early on, and
then systematically changed all uses of the longer form to the shorter
form when appropriate. And so the only thing we now use the longer one
for is to pass to child programs.
(Implementation note: The actual change is not very big, but while I was
about it I decided to make the test suite able to test with an absolute
REPO_BASE also, which is why the commit seems so large.)
----
This all started with a complaint from Damien Regad. He had an
extremely odd setup where his bashrc changed PWD to something other than
$HOME before anything else ran. This caused those two variables to
beceom inconsistent, and he had a 1-line fix he wanted me to apply.
I generally don't like making special fixes for for non-standard setups,
and anyway all he had to do was set the full path to REPO_BASE in the rc
file to get around this. Which is what I told him and he very politely
left it at that.
However, this did get me thinking, and I soon realised I was needlessly
conflating "relative versus absolute" with "able to be passed to child
programs". Fixing that solved his problem also, as a side-effect.
So I guess this is all thanks to Damien!
