Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Support change-set renumbering and ID collision resolution in ears-manager for concurrent PR branches

Open
  • Is something wrong?
#306 2 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
cli, tooling

Research direction

Start with ears-manager/internal/cli/branch.go and highestChangeSetNumber, then inspect change-set commands and tests in ears-manager/internal/cli/changeset_test.go. Reproduce the concurrent branch collision described in the issue and trace how manifests, .protobot/project.yaml, references, and store digests are maintained. Done when renumbering updates those records and change-set update --base-commit reports collisions with recovery guidance; the specified test should pass ears-manager check.

Written by the indexing model from the issue text.

Description

component:ears-manager enhancement feature ready-for-triage triaged

What happened

On PR #245 (https://github.com/redhat-et/ProtoBot/pull/245), the fix agent authored proposed change set CS-00002 (.protobot/change-sets/cs-00002.yaml) via ears-manager change-set create to govern updates to docs/architecture.md per AGENTS.md Rule 5.

Concurrently, PR #221 (evaluation corpus specification updates) was developed from main when main only contained CS-00001. Because both branches were isolated, PR #221 also created CS-00002 (.protobot/change-sets/cs-00002.yaml). PR #221 merged into main first (commit f13e178).

When maintainer @jerry-ng2 merged main into PR #245 (commit 22aba0f), both branches claimed CS-00002 for distinct change sets, creating a direct ID collision. ears-manager provides no command or migration procedure to renumber an existing change set or resolve duplicate sequence numbers. Because AGENTS.md Rule 5 strictly forbids editing change-set manifests or .protobot/project.yaml by hand, and ears-manager check validates store integrity and digests, the maintainer had to perform manual file surgery across multiple commits (37b3290, 7b4383c, 19b1b83): manually deleting cs-00002.yaml, recreating cs-00003.yaml, reapplying artifact operations via ears-manager artifact put, updating .protobot/project.yaml, and re-running impact analysis.

What could go better

High confidence that this is a recurring architectural problem for ProtoBot. ears-manager allocates sequential integer IDs (CS-00001, CS-00002, etc.) using highestChangeSetNumber in ears-manager/internal/cli/branch.go. In any repository where multiple pull requests containing proposed specification changes are developed concurrently, each branch will independently select the same sequential sequence number from its local baseline. When branches merge out of order, collisions are mathematically guaranteed.

Because ears-manager provides no change-set renumber command or automated collision recovery during change-set update --base-commit, recovering from a collision requires error-prone manual manifest surgery that directly violates AGENTS.md conventions against hand-editing registered artifacts. Neither autonomous agents nor human maintainers have a supported CLI path to resolve change-set ID collisions.

Proposed change

In redhat-et/ProtoBot, add change-set renumbering and collision-resolution capabilities to ears-manager:

  1. Add a new command: ears-manager change-set renumber --change-set <old-id> [--to <new-id>]:

    • If --to is omitted, calculate the next available sequence number across the working tree and canonical default branch refs using highestChangeSetNumber.
    • Rename .protobot/change-sets/<old-manifest>.yaml to <new-manifest>.yaml.
    • Update the id: field in the manifest.
    • Update all corresponding change-set references in .protobot/project.yaml.
    • Update any child records or active change-set operations referencing the old ID.
    • Re-calculate store digests so ears-manager check succeeds immediately.

  2. In ears-manager change-set update --base-commit <new-base>:

    • Check whether the proposed change-set ID already exists in the target base commit tree.
    • When a collision is detected, fail with a specific diagnostic (change_set.id_collision) and output actionable recovery instructions recommending ears-manager change-set renumber.

Validation criteria

In ears-manager/internal/cli/changeset_test.go, add an automated test exercising change-set renumbering:

  1. Initialize a test repository with CS-00001 merged on main.
  2. Create a proposed change set CS-00002 on a feature branch.
  3. On main, commit an independent proposed change set CS-00002.
  4. On the feature branch, run ears-manager change-set renumber --change-set CS-00002.
  5. Verify that the manifest is renamed to cs-00003.yaml, .protobot/project.yaml is updated with CS-00003, and ears-manager check passes with exit code 0 without manual file edits.

Generated by retro agent from https://github.com/redhat-et/ProtoBot/pull/245

Dominant language
Go
Stars
6
Forks
8
Avg merge
1d 5h
Merged PRs (30d)
84

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from redhat-et/ProtoBot

All issues in redhat-et/ProtoBot

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.