mirror of
https://github.com/l0ng-ai/openidea.git
synced 2026-11-06 16:08:05 +00:00
l0ng-ai
c3b7e34b22
* perf(vcs): filter the Git log with git log instead of a background search index The log built a persistent inverted index of every commit's message, authors and changed paths in the background, with a progress bar above the commit list, and walked trees itself to filter by path. Building it took minutes on large repositories, and filters were slow until it finished. - Text: plain text uses `git log --fixed-strings --grep` (with `--regexp-ignore-case` unless Match Case is on); text of 4+ hex digits also matches hash prefixes. Regex filters still match in-process. - Paths: `git log -- :(literal)<paths>` replaces the in-process path walk and its per-commit tree cache. It uses git's history simplification and, when the repository has a changed-path commit-graph, its Bloom filters. Glob characters in a path are literal. - Authors match against the commit metadata cache. - Removed the search tables, `index_log`, the `vcs_log_index` command and the indexing progress bar. The commit metadata cache stays. * docs(contributing): ask for screenshots only when a change alters what users see Removing a feature together with its UI, copy-only and non-visual changes now describe what was checked instead of attaching before/after screenshots. * fix(vcs): match case-insensitive non-ASCII Git log text in process git folds case only for ASCII under the C locale it runs with, so a case-insensitive filter like "ärger" missed "Ärger". Such text is now matched against commit messages directly. Path and text selection also ignore log.showSignature and log.follow from the user's config.
2.1 KiB
2.1 KiB
Contributing to OpenIDEA
These rules apply to everyone, and to any coding agent working on their behalf. Project layout, coding rules, commands and checks are in AGENTS.md.
Issues
- One problem or request per issue. Use the issue forms.
- Bugs: steps that reproduce the problem from a fresh start. A minimal sample project is the fastest way to get a fix.
- Features: state the problem and the acceptance criteria. A feature is ready to
build once a maintainer labels it
planned. - Labels track status:
needs-infowaits on the reporter,needs-decisionwaits on a maintainer,plannedis accepted,needs-acceptancehas a fix waiting to be checked.
Pull requests
- One problem per PR. If it resolves an issue, link it with
Closes #123. - Reproduce the problem first, or write a test that fails before the fix.
- Fix the cause, and check whether the same cause breaks anything nearby.
- Keep the diff focused. Unrelated refactors go in their own PR.
- Title: Conventional Commits, e.g.
fix(editor): keep the caret visible after folding. - Fill in the template. Keep the description short and in plain words. If it doesn't fit in a few sentences, the PR is probably too big.
- How it was verified is required: the commands you ran and their results, and what else the change could affect. Changes to what users see need before/after screenshots; multi-step interactions need a recording. UI that goes away with a removed feature, copy-only and non-visual changes don't; say what you checked instead.
- If a change needs a product decision you can't make, ask in the issue and stop rather than guessing.
Plugins: pull requests here add or change official plugins (plugins/official/)
and the plugin API. Community plugins live in their authors' repositories and
are listed through l0ng-ai/openidea-plugins;
see plugins/README.md § 8.1.
A check on each PR adds needs-info when the verification section is missing, and removes it once it's filled in.