| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |\
| |
| |
| | |
merged from upstream tag v3.6.12
|
| | |\
| | |
| | |
| | | |
v3.6.12
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This affects the mirroring code and documentation:
"slave"/"slaves" are now "copy"/"copies".
Backward compatibility should be maintained; you do not need to
change either your gitolite.conf, or any scripts you have
written on top, until you are ready to do so. (This in turn
means the word "slave" will still be present in the code, though
only just as much as needed.)
Should you wish to make this change, you need to migrate to the
latest version (which is also tagged as 3.6.12, so if you want
to wait till the distros pick it up wait for that), and then:
- In the gitolite.conf file, change `option mirror.slaves` to
`option mirror.copies`.
- If you have any scripts that use the `gitolite mirror list
slaves` command, change to `gitolite mirror list copies`.
sitaram
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This command:
ssh git@host config my/wild/repo --add gitweb.owner "Sitaram Chamarty"
doesn't work. Sshd converts it to
config my/wild/repo --add gitweb.owner Sitaram Chamarty
so by the time src/commands/config sees this, that looks like two
"values" ("Sitaram" and "Chamarty") instead of one.
We can't do much about this in the general case; that's how sshd rolls.
I suppose we could, in parse_soc() in src/gitolite-shell, use something
like Text::ParseWords instead of a simple "split" (and then send in
arguments with backslash-escaped spaces etc) but that's too big a change
impacting too many things. Not going to happen for this simple need.
The simplest way out is for src/commands/config to learn that multiple
trailing arguments are actually one space-separated argument.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Technically, the previous behaviour could even be called a "feature", in
that it allowed you to use regexes for users -- contradicting the
documentation! -- in the following way:
@foo = u[123] u9
repo bar
RW+ = @foo
which would enable users u1, u2, and u3 to access bar.
I thought for a bit about this, and decided to fix the code rather than
the documentation.
Leaving it as a quirk was another alternative, but it would only be a
quirk [1], and an incomplete one at that because it only works for
patterns inside *groups*, not patterns that are actually *on* the rule
line (e.g. RW+ = u[123]). No good...
Thanks to Steven Peckins for catching this.
[1]:
$ dict quirk
From The Collaborative Fictional Dictionary of English v.0.48 [gcide]:
Quirk \Quirk\ (kw[~e]rk), n. [Written also {querk}.]
1. a bug that doesn't do enough harm to be shot down with extreme
prejudice, and in fact might even be said to do something
vaguely OK. If you squint. And if it's a Sunday.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There are two points to consider here:
- is the user trying to delete all hooks for a repo?
- is it a reserved hook (one we should not be touching)
The second one is more important; the first one is a spurious warning
that is at worst an aesthetic problem.
Unfortunately, when refactoring to fix a bug in 7898f9b, I gave higher
priority to the wrong issue, and the more important one was not checked
when the less important one was "true".
As a result, control moved to the second stage, where hooks were
symlinked to the multi-hook driver. Including the all important
'post-update' hook in 'gitolite-admin'.
Ouch!
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If a reference is deleted in a repository where this virtual ref is
active, the script is not capable of handling it correctly:
remote: fatal: bad object 0000000000000000000000000000000000000000
remote: error: unable to find 0000000000000000000000000000000000000000
remote: fatal: Not a valid object name
0000000000000000000000000000000000000000
This patch fixes the issue.
[commit message and patch modified slightly by Sitaram]
|
| | | |
| | |
| | |
| | |
| | | |
git 2.18 (and above) does not leave an empty section header lying around
when the key and value are deleted using 'git config --unset'
|
| | | | |
|
| | | |
| | |
| | |
| | | |
[git-debrebase make-patches: export and commit patches]
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Git-debrebase doesn't work cleanly out of the box with 1.0 packages
using quilt manually.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This follows the suggestion of
http://gitolite.com/gitolite/install.html
Gbp-Pq: Name fix-paths
|
| |\ \ \
| | |/
| |/|
| | |
| | |
| | | |
First breakwater merge.
[git-debrebase anchor: declare upstream]
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Delete debian/patches, as part of converting to git-debrebase format.
[git-debrebase convert-from-gbp: drop patches from tree]
|
| | | | |
|
| |\| |
| | |
| | |
| | | |
v3.6.11
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Nick Cleaton (nick@cleaton.net) found and reported a security issue
caused by trusting the remote rsync too much. It appears that rsync
cannot -- without special precautions -- be used in any "restricted"
environment.
Gitolite ships with a "bundle helper" called "rsync" (disabled
by default; more details below). This fix tightens up this
helper to close this hole.
TLDR for administrators and packagers:
1. Am I affected?
Look in ~/.gitolite.rc for "rsync"; if it is there, you are
affected.
This is NOT an essential program, and it is not enabled by
default. You (or a previous administrator of your site)
would have to have explicitly enabled it for you to be
affected.
2. What's the quick fix?
Comment out the "rsync" line in ~/.gitolite.rc IMMEDIATELY.
DO NOT LEAVE IT ENABLED IF YOU ARE UNABLE TO UPGRADE IMMEDIATELY!
Uncomment it only after you have upgraded or patched.
3. That bad, huh?
Sadly, yes :(
DETAILS:
This program is not a core program. Despite the name, it will not
function as a generic "rsync".
This is *only* meant to help out people who are on flaky connections,
trying to clone a large repo.
Because git clone is not resumable, one common technique is to have
someone create a "bundle", then download the bundle to seed the local
repo, then "git fetch" to finish off. Since the bundle is a single
file, you can use resumable mechanisms (like rsync) to download it.
What this command does is allow that kind of bundling to happen
automatically, if an administrator enables it.
The user simply rsyncs a bundle file using his gitolite
credentials. As a result, the rsync helper command that ships
with gitolite is executed. This program manages the creation
and expiry of bundle files, then passes control to the *real*
rsync program to perform the actual data transfer.
It is this last step that requires special care when used in a
restricted environment, resulting in the need for this patch.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
dc13dfc introduced a block on accessing repos which are in the process
of being moved into gitolite's control.
This block was (a) in gitolite-shell, which would catch all git-client
activity and (b) in list_phy_repos(), which would prevent those repos
from being seen by the 'info' command.
Unfortunately that was stupid; it also blocked 'gitolite setup' itself,
because setup uses list_phy_repos!
The correct place to put this was always going to be access(), but I had
initially shied away from that because it would cause a slight glitch in
the working of any POST_COMPILE trigger scripts that used the access()
function on any of the newly migrated repos.
But nothing else really works. As a result, the step where you run
`gitolite setup` when importing now becomes:
gitolite compile
gitolite setup --hooks-only
gitolite trigger POST_COMPILE
|
| |\ \ \
| | | |
| | | |
| | | | |
[dgit --overwrite]
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* Bug fix: "[INTL:pt_BR] Brazilian Portuguese debconf templates
translation", thanks to Adriano Rafael Gomes (Closes: #811528).
[dgit import package gitolite3 3.6.7-2]
|
| | / /
| | |
| | |
| | | |
[dgit import orig gitolite3_3.6.7.orig.tar.gz]
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | | |
merged from github
|
| | |\| |
| | |/
| |/|
| | | |
v3.6.9
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
David Bremner found that 'gitolite trigger foo', where foo is some
arbitrary string, silently no-ops.
The "gitolite trigger X" command only makes sense when X is POST_COMPILE
or POST_CREATE, or, if it's a custom trigger type [1], when there is a
section with that name in the rc file with a list of scripts to run.
Anything else is an error, and should not silently no-op.
[1]: for example, http://gitolite.com/gitolite/odds-and-ends/#using-pubkeys-obtained-from-elsewhere
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Björn Kautler pointed out that, when a repo is being migrated into
gitolite as per the documentation [1], there is a gap between the actual
move of the repo and the rest of the process where a user can gain read
or write access to the repo, which he would *not* have had after the
completion of the process.
My first thought was to document this, and advise people to use the
'writable' command to disable writes, but there is nothing as simple and
painless to prevent reads. (On the plus side, this kind of racy read
access can only happen if the conf is using the "deny-rules" option to
restrict reads; without that, it makes no difference -- i.e., he gets no
access that he would not have got later anyway).
But eventually I realised that documentation was frustrating, for
various reasons, and that at least in this case there is a way to fix it
in the code -- just block all access to a repo that is in
~/repositories, but which does not yet have the update hook setup
correctly. Plus, the code does not impact anything else, and is
basically just an extra check.
[1]: http://gitolite.com/gitolite/basic-admin/index.html#appendix-1-bringing-existing-repos-into-gitolite
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Björn Kautler pointed out that for VREFs suffering fallthru, the
interpretation of the result of access would be wrong.
Initially, I was reluctant to make that adjustment here. The 'access'
command is meant to be just a shell entry point for the access()
function, nothing more, so bringing in adjustments that occur elsewhere
in gitolite would not be right.
But it makes automated testing for VREF rules more difficult (and VREFs
are already hard enough for most people to understand), so I caved.
Hopefully this won't turn into a slippery slope...
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
C was being handled incorrectly, while M was not even considered (and
would behave as if MERGE_CHECK was set)
thanks to Björn Kautler
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | | | |
|
