You can use your own Woodpecker instance with Codeberg. I do this at work and privately and it works great and is much faster than the free CI that Codeberg can afford.
I'm really interested in doing this - did you follow any guides or find helpful tutorials online? At the moment I'm using Codeberg's free CICD, but it's limited and I'd rather run my own.
There is no place called 'Udem' in Germany. There is a place called Uden in the Netherlands. Close to it is the military Volkel Air Base. It has fighter jets and nuclear bombs. https://en.wikipedia.org/wiki/Volkel_Air_Base
> NATO was monitoring the Baltic States air space from ground radars and from a Gielenkirchen based AWACS several hundred kilometers back near the German/Polish border.
There is also no place called „Gielenkirchen“. It‘s likely a typo of „Geilenkirchen“, which indeed does have a NATO base. But it is also at the German/Dutch border, while the article places it at the German/Polish border.
I am questioning the rest of the article based on these findings. They are straight-forward to check before publishing.
> ...based AWACS several hundred kilometers back near the German/Polish border
This should also have triggered the 'fact checker alarm bells' because there are no NATO bases in the area of former East Germany to this day (honoring the agreement with the late Soviet Union to not station foreign NATO troops in former East Germany - e.g. the only "no NATO East expansion promise" that actually exists in writing) - and AFAIK apart from the Eurofighter Luftwaffengeschwader 73 in Rostock-Laage (also not exactly close to the Polish border) there is no presence of the German airforce in East Germany either.
Although tbf, the sentence could also be read as the Geilenkirchen-based AWACS plane operating several hundred kilometers back (from Estonia) near the German/Polish border - which I guess makes a lot more sense than moving Geilenkirchen several hundred kilometers to the east :)
In any case I agree that it's a poorly written article and should be classified as fiction until confirmed by more reliable sources.
Nothing greenlit in a “closed-door EU working group session” can become law. These things need to go through all phases of legislation including the approval of parliament.
So yes, if you don’t like chat control, talk to your MEPs and stop voting in populist ministers and council members/presidents.
It speeds up a lot on directories with many binary files and committed dot files. To search the dot files, -uu is needed, but that also tells ripgrep to search the binary files.
On repositories with hundreds of files, the git ls-files overhead a bit large.
Can you provide a concrete example where that's faster? ripgrep should generally already be approximating `git ls-files` by respecting gitignore.
Also, `-uu` tells ripgrep to not respect gitignore and to search hidden files. But ripgrep will still skip binary files. You need `-uuu` to also ignore binary files.
I tried playing with your `rgg` function. First problem occurred when I tried it on a checkout the Linux kernel:
$ rgg APM_RESUME
bash: /home/andrew/rust/ripgrep/target/release/rg: Argument list too long
A checkout of my repository [0] with many pdf and audio files (20GB) is slow with -u. These data files are normally ignored because 1) they are in .gitignore and 2) they are binary.
The repository contains CI files in .woodpecker. These are scripts that I'd normally expect to be searching in. Until a week ago I used -uu to do so, but that made rg take over 4 seconds for a search. Using -. brings the search time down to 24ms.
Oh I see now. I now understand that you thought you couldn't convince ripgrep to search hidden files without also searching files typically ignored by gitignore. Thus, `git ls-files`.
Yes, now it makes sense. And yes, `-./--hidden` makes it moot. Thanks for following up!
Yes, I agree, `git ls-files` can indeed be faster than just `rg --files`. On my Chromium checkout:
$ hyperfine --output pipe 'rg --files' 'git ls-files'
Benchmark 1: rg --files
Time (mean ± σ): 141.2 ms ± 7.1 ms [User: 1134.5 ms, System: 376.3 ms]
Range (min … max): 128.7 ms … 154.8 ms 20 runs
Benchmark 2: git ls-files
Time (mean ± σ): 54.9 ms ± 1.7 ms [User: 41.7 ms, System: 13.1 ms]
Range (min … max): 52.2 ms … 62.0 ms 54 runs
Summary
git ls-files ran
2.57 ± 0.15 times faster than rg --files
But the semantics here are important, because ripgrep doesn't only try to approximate `git ls-files`. It also needs to deal with `.rgignore` and `.ignore`. And no git repository state will help there. ripgrep also supports respecting `.gitignore` even when it isn't inside a git repository.
After writing this comment, I read the man page again and found the -. flag which can be used instead of -uu.
Searching in hidden files tracked by git would be great but the overhead of querying git to list all tracked files is probably significant even in Rust.
The point is to search hidden files that are tracked by git. An example is CI scripts which are stored in places like .woodpecker, .forgejo, .gitlab-ci-yml.
Or whatever you need to whitelist specific hidden directories/files.
For example, ripgrep has `!/.github/` in its `.ignore` file at the root of the repository[1].
By adding the `!`, these files get whitelisted even though they are hidden. Then `rg` with no extra arguments will search them automatically while still ignoring other hidden files/directories.
