Skip to content

feat: add stageOnMove setting for visual-only change lists - #7

Open
ChaoticLuna wants to merge 1 commit into
maxinne-dev:mainfrom
ChaoticLuna:feat/configurable-stage-on-move
Open

ChaoticLuna wants to merge 1 commit into
maxinne-dev:mainfrom
ChaoticLuna:feat/configurable-stage-on-move

Conversation

@ChaoticLuna

Copy link
Copy Markdown

Motivation

Currently, moving a file into a change list implicitly runs git add (and moving it to the Unversioned list unstages it). This couples change list membership to the Git index: a purely organizational action silently changes what the next commit will contain, which makes accidental commits easy.

In JetBrains IDEs, changelists are a purely organizational concept — grouping files never touches the staging area. This PR makes that behavior available here as an opt-in setting, enabling a visual-only grouping mode.

Changes

  • package.json: register a new gitChangeLists.stageOnMove boolean setting (default true), with a description explaining that false makes grouping purely visual and that the "Stage Change List" command should be used to stage explicitly.
  • src/utils/constants.ts: add CONFIG.STAGE_ON_MOVE key.
  • src/services/configService.ts: add getStageOnMove(), following the existing getCommitGuardEnabled() pattern. It reads the live configuration on every call, so changing the setting takes effect immediately without a reload.
  • src/services/changeListManager.ts:
    • moveFiles: when stageOnMove is false, skip both stageFiles (moving into a regular list) and unstageFiles (moving to the Unversioned list); only the internal fileMapping is updated.
    • getFilesForList: when stageOnMove is false, untracked files respect their explicit list mapping instead of always appearing in the Unversioned list (files are no longer implicitly staged, so untracked files can now legitimately belong to a regular list); unmapped untracked files still appear in Unversioned.
    • ConfigService is injected via the constructor.
  • src/extension.ts: pass the existing configService instance to ChangeListManager.

Behavior

  • Default (stageOnMove: true): no behavior change — moving files stages/unstages them exactly as before.
  • stageOnMove: false: change lists are purely visual groups; moving files between them never modifies the Git staging area. The "Stage Change List" and "Commit Change List" commands are unaffected and continue to stage/commit explicitly.

⚠️ This PR was drafted by Kimi K3 (AI coding assistant) and is pending human review.

Testing

  • npm run compile (tsc) passes cleanly.
  • npm run lint could not be run: eslint is not installed in the project's devDependencies.
  • Manual review and interactive testing in the Extension Development Host are still pending.

Moving files between change lists implicitly staged/unstaged them in
Git, coupling list membership to the index and making accidental
commits easy. Add a gitChangeLists.stageOnMove setting (default true,
preserving current behavior). When disabled, change lists are purely
organizational (JetBrains semantics) and never touch the index;
untracked files respect their explicit list mapping, and staging is
done explicitly via the 'Stage Change List' command.

Co-authored-by: Kimi K3 <noreply@moonshot.ai>
@gemini-code-assist

Copy link
Copy Markdown

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

@ChaoticLuna
ChaoticLuna marked this pull request as ready for review July 27, 2026 06:59
@gemini-code-assist

Copy link
Copy Markdown

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant