| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While we were meaninglessly debating (on the mailing list) the merits of
showing the wild repo regexes to a *human*, someone came up with a
reasonable need for an option to *not* show them so that certain
automated tasks can be a wee bit simpler. Note that I still think the
regexes *should* be shown to the user by default; we're just adding an
option to explicitly suppress them.
15:31:59 <hiroki> sitaram: Thanks ! The most common use case would be
for a sanity check script running on slaves that will check what
repositories it has locally, and compare it with the output of info
to their master. That way they can be certain all repositories are
synced over properly. Second step would be to check all commit
hashes of all repositories locally and their respective master.
|
| | |
| |
| |
| |
| | |
...to see stdout correctly (vis-a-vis stderr) in update hook and
expand-deny-messages
|
| |\|
| |
| |
| | |
v3.6.8
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We have a system with thousands of repositories located on disks where:
1. write operations are much slower than read operations
2. IO is burstable but is throttled after a certain limit
In such conditions, writing out 10-15 git config settings per each of the
15,000 repositories resulted in around 200,000 calls to git-config and
200,000 disk writes to 15,000 files on every gitolite-admin push, even
if there were no changes to any git configs.
With this change, we call git-config once to read the entirety of the
git config for the repo, and issue writes only if there are changes to
any of the settings.
Similarly, we only touch git-daemon-export-ok if such file doesn't
already exist to avoid another few thousand unnecessary writes.
As a result, our gitolite-admin push times went from 10-12 minutes to 20
seconds.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Actually this is a revert of the previous patch, combined with putting
that logic where it belongs (and in the process doing it more cleanly)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Basically, Linus complained that git-daemon is happy with the trailing /
so why does gitolite choke on it?
Fair enough.
Actual implementation: we choose to kill the "/" at the point of entry,
rather than weaken the sanity() function.
ref: https://groups.google.com/forum/#!topic/gitolite/zLMoQ7u28gk
|
| | | |
|
| | |
| |
| |
| |
| | |
we may also need a linter for this whole thing later, depending on usage
and any reports coming in.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
What? That isn't a good enough commit message? Well then, go look up
the thread on the mailing list (subject: "gitolite setup vs
ssh-authkeys-split")
:-)
PS: Thanks to Tony Finch for the discussion!
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Background:
For explicitly named repos in gitolite.conf ("repo foo bar" as
opposed to "repo @group-name" or "repo [a-z].*"), the compiled rules
are placed in a file called "gl-conf" in the repo's directory.
In addition, an entry is made in a hash called "split_conf" in the
main compiled conf file (~/.gitolite/conf/gitolite.conf-compiled.pm).
The crucial bit is this: if a repo does not have an entry in the
split_conf hash, its gl-conf file will not be honored.
Why is this? Because there are situations where that file may be
out of date, and the rules within should not be in effect. For a
simple example, consider this conf
repo seven
RW+ = u1
RW = u2
Now, management decides that "seven" needs to be assimilated into a
large group called "borg":
# add seven to borg
@borg = seven
# seven's rules are now deleted
When you make this change and push, users u1 and u2 should not get
access (unless the rules for @borg happened to allow them). That
is, the gl-conf in the repo-dir is considered an orphan, and must
not be included in rule processing.
Since there is now no "seven" entry in split_conf, this is exactly
what happens -- gl-conf is ignored.
(Note: one might argue that gitolite compile should go and delete
these orphaned gl-conf files, but that's yet another "full disk
scan" overhead.)
What this patch does:
This patch allows an admin to override this safety feature, and say,
in effect, "include orphaned gl-conf files in the rule processing; I
know what I am doing". The admin enables that by adding an rc
variable called ALLOW_ORPHAN_GL_CONF and setting it to "1".
How does this help:
This wouldn't be useful without some way of updating an individual
repo's rules directly into its gl-conf file.
contrib/commands/compile-1 does exactly that (see notes within that
file for information, assumptions, warnings, etc.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
with the new "template-data" section, it becomes important to be able to
visually know if you're entering something in the wrong section
(template stuff outside the begin/end markers, or normal stuff inside).
(unfortunately I only know vim; maybe others can help with other
editors' setups?)
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
...a la 'gl-perms' for role memberships
|
| | |
| |
| |
| |
| | |
...I was lazily letting them run over ALL repos. (And I am still lazy
because I did not do one of them yet; see comments in that file).
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
...these were found when the caching code was being developed. We have
reverted the caching, but these optimisations are not related to caching
so we keep them.
|
| | |
| |
| |
| |
| |
| |
| | |
This reverts commit 41b7885b77cfe992ad3c96d0b021ece51ce1b3e3.
Some parts of this change may come back later, but the caching logic
will not.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fedora has 42000 or so repos, and a 'gitolite compile' was taking too
long.
This set of changes reduces the number of stat() and other calls from 9
to 2 per unchanged, existing repo. (The expectation is that only a few
repos' rules are being changed each time, so this helps somewhat
optimise the others not to take the same amount of time).
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Signed-off-by: Till Maas <opensource@till.name>
(with minor whitespace changes by sitaramc@gmail.com)
|
| |\|
| |
| |
| | |
v3.6.7
|
| | | |
|
| |\| |
|
| | | |
|
| | |
| |
| |
| | |
(thanks to Mathieu Arnold for catching this, and for an initial patch)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
normally I don't care too much about inefficiencies that show up during
a push to the gitolite-admin repo, but this one shows up even when a
normal user creates a single wild-card repo -- it runs the repo-specific
hooks trigger on ALL existing repos!
no one noticed or complained, so perhaps it *actually* wasn't that
visible a problem, but it's an easy fix anyway.
(TBH, there's still a slight inefficiency. When a new (non-wild) repo
is added to gitolite.conf, that particular one gets processed twice --
once in POST_CREATE, and once in POST_COMPILE... but *shrug*. If no
one noticed the much bigger O(n) inefficiency we just fixed, this O(1)
inefficiency hardly matters.)
|
| | |
| |
| |
| |
| | |
see https://groups.google.com/forum/#!topic/gitolite/-PvYRleGKHQ for
details
|
| | |
| |
| |
| |
| |
| | |
Because of a one-bit typo, this only matched the fingerprint up until
the first upper-case letter; this led to false-positive messages about
hash collisions.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
The string "@group" is replaced with a space separated list of member
names if it is a valid group. Otherwise it is left alone.
|
| | |
| |
| |
| | |
(thanks to Dieter on the mailing list for catching this!)
|
| | |
| |
| |
| | |
...was incomplete/ambiguous
|
| | | |
|
| |\|
| |
| |
| | |
v3.6.6
|
| | | |
|
| | |
| |
| |
| | |
see https://groups.google.com/forum/#!topic/gitolite/O7lKFU2okl8
|
| | |
| |
| |
| |
| | |
Thanks to Alexander Groß for catching this. Basically, the access command was
ignoring the presence or absence
|
| | |
| |
| |
| | |
See mailing list thread, subject line "Readme-extensions"
|
Sitaram Chamarty
Robin H. Johnson
Konstantin Ryabitsev
Sitaram Chamarty
Till Maas
Alex Vandiver
kwadronaut
GitWeb