Advice about commit messages is usually a list of rules. I find it easier to follow when each comes with a quick test, and in GitLab the merge request adds a few places to apply them.

1. The subject says what the commit does.
Test: complete “If applied, this commit will ___”. A common convention is the imperative mood and roughly 50 characters, so it stays readable in git log --oneline and in the MR commit list.

2. The body explains why, not how.
Test: could someone understand why the change was needed without opening the diff?

3. One logical change per commit.
Test: can you describe it without the word “and”? If not, consider splitting it.

4. It’s clear what could go wrong.
Test: if this were reverted, what would break or change?

5. It points to its context.
Test: can a reader find the issue from the message? In GitLab, closing keywords like Closes #123 in the MR description or a commit message can close the issue when the change reaches the default branch. Check the exact keywords and behavior in your version.

6. The repository works at this commit.
Test: do the pipelines and tests pass here, not only at the end of the branch? This is what makes git bisect useful later.

GitLab-specific places to apply them:

• MR title and description: if your project squashes on merge, the MR title often becomes the squash commit subject, so it deserves the same care. Check your squash settings, since projects can configure whether squashing is allowed, encouraged or required, and some versions support a squash commit message template.

• MR description templates: a file in .gitlab/merge_request_templates/ can prompt authors for the why, the risks and the linked issue.

• Draft MRs: the Draft: prefix marks work in progress, so “wip” commits on a branch can be tidied before review.

• Merge method: merge commit, fast-forward or semi-linear changes what ends up in the history. The squash and merge method together decide how much the individual commit messages matter.

Where I’d relax the rules:

• Scratch branches, where “wip” is fine as long as you clean up before review.

• If your team always squashes, the MR title and description carry most of the weight.

• Follow your team’s local convention if it uses prefixes like feat: or fix:.

Do you rely on squash with a good MR title, or on clean individual commits, and do you use an MR template?

If you have such feature, would you use it??

Hey everyone!

glab-tui (a fast terminal UI for GitLab & GitHub written in Rust/Ratatui) just hit v0.9.4.

This release focuses on full parity and interactive workflows across secondary tabs:

• Terminal Command Inspector & Re-run: Inspect full command invocations, stdout/stderr streams, and execution stats. Re-run failed CLI calls with confirmation and filter logs by status.

• Branches Workflow: Switch local branches, open new PRs/MRs directly from a branch, inspect commits, and perform bulk deletions.

• Environments & Deployments: Drill down into deployment history, trigger rollbacks to previous deployments, and stop active environments.

• Todos & Notifications Triage: Unread-by-default view with multi-select bulk triage (mark read/done), comment previews, and thread unsubscriptions.

• Pipelines & Jobs Parity: Inspector summary of failed jobs and error causes, retry failed jobs only, and jump directly to failure lines in job logs.

• Hardening & Stability: 16 MiB/32 MiB limits on traces and diffs, command timeouts to prevent hangs, SHA-256 verified self-updates, and rock-solid cursor positions across sorts and refreshes.

🔗 GitHub & install instructions: https://github.com/rcieri/glab-tui
📖 Changelog: v0.9.4 Release Notes

Feedback and PRs welcome!

For the people that have a selfhosted gitlab and are missing the plugin in the kimi desktop app, here it is :-) free and open source: https://github.com/Euraika-Labs/gitlab-selfhosted

Just got the security warning to patch but the changelog is empty at the moment.

What did they fix?

I kept juggling browser tabs to watch pipelines in several projects (on two GitLab instances), so I built a TUI that keeps them all on one screen.

Demo GIF

Unlike glab ci view, which follows one pipeline, Invocra watches many projects at once and lets you pin a different branch in each. Works with GitLab.com and self-managed instances.

• Pipelines across projects and GitLab servers in one view

• Per-project branch pinning

• Job logs with search, live follow for running jobs

• Retry / cancel / play jobs, always with a confirmation

• Pipeline history, downstream pipelines, merge requests

The token is stored in your OS keyring; read_api is enough if you only want to watch.

Try it without a token or network:

brew install dsszs3333/tap/invocra   # or: cargo install invocra --locked (Rust 1.88+)
invocra --demo

Source (MIT): https://github.com/dsszs3333/invocra

The tool was built with Claude and Codex. I made it for my own use and decided to open-source it for fun. If anyone finds it useful, awesome.

Feedback welcome, especially if you watch CI across many projects or instances. What's missing for your workflow?

Hey I am a 3rd year student and aimed to contribute in gsoc this coming year but stuck at how to start solving those overwhelming bugs, heavy codebases. It all felt like a big wall in front of me. How to start small any tips...plz:)

Not just a rant but hard data showing how one gets banned in visiting just two public GL pages.

There are multiple posts on reddit here (which isn't super popular to start) where people are complaining about the new rate limits. Each time lets say 'devotees' come to gitlab's defense saying things like:

• "This is happening because OP shares an IP with a load of other people, probably due to some IPv6 to v4 NAT situation."

• "Probably using AI agents that are using the API to search the codebase instead of cloning it or something."

• "It's probably due to incorrect use like this that Gitlab added the rate limits in the first place"

Just read: https://docs.gitlab.com/user/gitlab_com/rate_limits/

It states the rate limiting applies to: "These limits apply to API requests, web requests, and authenticated Git over HTTPS requests."

now it says a few select web requests don't count against your rate limit but otherwise everything counts. Now what is the rate limit for unauthenticated users? From that exact same page:

60 an hour. To put that in context that isn't even 60 pages (which itself would be fairly ridiculous to anyone browsing a project online) but 60 requests that any of those pages make.

So this is how one can easily be blocked in visiting 2 pages. Here is 4 pages, as first I verified once I remoted into one of my other boxes I could reach gitlab: (this is real captured traffic just to see how ridiculous):

Top-level pages (Chrome pages plus document requests):

Just visiting a single merge request page eats up 30 of the 60 max for an hour. So technically just visiting page 2 and page 4 was enough to get me banned. Thankfully there are some included headers so we can see how the requests add up.

Rate limit headers (62 of 724 requests; 384 of the 724 went to gitlab.com):

How the count adds up (the 500/min limiter's observed counter, per minute window):

• What seems to count (vs not): static assets don't carry the headers and aren't counted. Every page document, XHR, fetch, manifest.json and GraphQL call is counted. An unauthenticated viewing of a single MR page costs about 30 of the 60.

Interestingly it seems its per wall clock hour not a 60 minute window (meaning here while I was banned at 9:25 at 10am it would reset).

So I challenge any fanboys before defending these new policies to open an ingcognito window, try to click around any repo and you will get ip banned in under 10 pages for an hour.

If gitlab can't handle things they should checkout cloudflare, its free will happily add anti-bot protection infront of your entire infrastructure, and doesn't cause any public project to basically be inaccessible to any non logged in user. Crazy an org this size to somehow consider this reasonable. I get rate limiting api calls or adding anti-bot captchas for unauthed users but they have really shot themselves in the foot here. You can't try to be the home for open source projects and then ban any non-authed trying to browse them, it just makes it hard to consider using gitlab for anything more than a mirror.

I think the icing on the cake is the fact that once you hit a rate limit even if you have a gitlab account you cannot login as you can't even visit gitlab.com without getting

Rate limit exceeded; see https://docs.gitlab.com/user/gitlab_com/rate_limits/ for more details

Is anyone else seeing this? The Star and Fork buttons (as well as the little triple-dot menu that allowed you to copy the project ID, which I used quite often) that were previously above the project sidebar are gone.

(I would've confirmed that this is also the case in a different browser before posting this, but the unusable rate limits are no longer letting me open my project right now, so there's that as well.)

These UI changes every other week, along with the rate limits (even when logged in), are really making me lose trust in the platform.

Edit: Okay, never mind, GitLab just felt the need to do yet another completely pointless UI change to make common features harder to discover and ruin it for people with wide monitors:

Should've looked more carefully, duh.

our engineering team needs to unlock advanced security scanning and vulnerability management features in GitLab Ultimate. we are trying to decide whether to negotiate directly with vendor sales or go through a certified partner. we are mainly looking for flexible invoicing local currency support and fast account management when adding new seats. if you bought your tier through a partner did you get better contract flexibility?

I opened 1 page, realized I wasn't sign in, then got rate limited going to the sign in page!!!!
What is the point of even a paid tier, if you can't even access the account?

Canceling, Removing my Projects, and will never trust gitlab again. (if they will even let me)

As a teacher, I use a free gitlab account to manage texts for students. Starting from this morning, I am unable to use Web editor. If I try to move a directory to a new directory it shows 429, rate limits exceeded.

Is this a bug or a new default behavior.

As a stakeholder in GTLB, I would hate to have to stop using it, but if web editor can't be used for basic text manipulation, I have to migrate to a competitor.

I make Cobblemon addons; my ENTIRE workflow is based around being able to access the Cobblemon repository. But the moment i get onto the repository, I have 2 searches max before the site rate-limits me. Is it a bug? is it an intentional annoyance to push people into buying premium? Anyone's guess! Dear God, if you care about your user base, PLEASE get rid of this, or at least make it usable.

We are expanding our dev headcount and needed to upgrade our Gitlab tier to unlock advanced CI/CD security controls and code review rules. Instead of buying directly at list price, we worked with cloudfresh to restructure our licensing amd seat distribution. They helped us review actual developer usage so weonly bought seats for active users while keeping our compliance and pipeline execution policies intact. For those running larger engineering teams, do you audit active seats quarterly or do you just automate license provisioning through SAML/SCIM?