Add repository-wide commit search across branches
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 35/100
Rechercherichtung
Lies zunächst die vorhandenen Implementierungen der Tools search_commits und list_commits sowie deren GitHub-API-Aufrufe. Prüfe, ob die API die Suche nach Commits im gesamten Repository mit Filtern für Autor und Datum unterstützt, und ermittle anschließend das passende Tool-Design und die passenden Tests. Erledigt ist die Aufgabe, wenn passende Commits über nicht standardmäßige Branches hinweg mit Paginierung und nützlichen SHA- oder ref-Metadaten zurückgegeben werden.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Describe the feature or problem you’d like to solve
The current search_commits tool searches commit messages on the repository's default branch only. This makes it difficult to reliably discover work performed by a developer on feature, bugfix, or other non-default branches that have not yet been merged.
For example, a developer may make several commits on feature/worklog-ai during the day while the repository's default branch is development. Those commits will not be returned by search_commits until they are merged into the default branch.
Using list_commits does allow specifying a branch through the sha parameter, but discovering a user's activity across an entire repository would then require listing branches and querying commits for each branch individually. This becomes inefficient for repositories with a large number of branches and also creates significant duplication because branches frequently share commit history.
A repository-wide way to find commits by author and date, independent of the branch on which they currently exist, would make the MCP server much more useful for developer activity, worklog, analytics, and code-agent workflows.
Proposed solution
Add a tool or extend an existing tool to support repository-wide commit discovery across branches.
For example:
search_repository_commits
Parameters could include:
owner— Repository ownerrepo— Repository nameauthor— GitHub username or emailsince— Start of the time range in ISO 8601 formatuntil— End of the time range in ISO 8601 formatpage— Pagination pageperPage— Results per page
The tool should return commits belonging to the specified repository and matching the author/date filters regardless of whether the commits are currently reachable from the default branch.
Ideally, results should include the commit SHA and enough metadata to identify the relevant branch/ref when possible.
The implementation should avoid requiring clients to enumerate every repository branch and call list_commits separately for each branch.
An alternative would be to extend search_commits with an explicit repository-wide/non-default-branch mode if that fits the existing tool design better.
Example prompts or workflows (for tools/toolsets only)
-
"Show me everything I committed to
owner/repositorytoday, including commits on feature branches that haven't been merged yet." -
"Find all commits by
usernameinowner/repositorybetween August 31 and September 1, regardless of which branch they were made on." -
"Generate a daily worklog for
usernamebased on all commits made in this repository today, including unmerged feature branches." -
"Find all work performed by
usernamein this repository during the last 7 days, including commits that are not present on the default branch." -
"List the commits made by
usernamein this repository today and group them by branch or related work."
Additional context
This is particularly useful for developer productivity and worklog workflows.
A common development workflow is for developers to work on feature or bugfix branches and merge them into main/development later. A daily activity query should not require those commits to already be merged.
The current search_commits behavior is documented as searching commit messages on the default branch only. list_commits can target a specific branch using sha, but using it to discover all user activity requires enumerating branches, which does not scale well for repositories with many branches.
The desired behavior is therefore a repository-level activity query that can efficiently identify commits by author and time range without requiring clients to know the relevant branches beforehand.
- Vorherrschende Sprache
- Go
- Sterne
- 33.1k
- Forks
- 5k
- Ø Merge
- 2 T. 3 Std.
- Gemergte PRs (30 T.)
- 18
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus github/github-mcp-server
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
github/github-mcp-server#3235 ·
-
enhancement
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
github/github-mcp-server#3042 · 2 Kommentare ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
github/github-mcp-server#3032 · 1 Reaktion ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
github/github-mcp-server#2803 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
github/github-mcp-server#2740 ·
Alle Issues in github/github-mcp-server
Ähnliche Issues
-
agentic-workflows
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
-
agentic-workflows
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
microsoft/agent-framework-go#1179 ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
-
[Bug]: OLLAMA_KEEP_ALIVE="5m" / "24h" crashes Ollama embedding and vision models with ValueError Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
infiniflow/ragflow#20223 · 1 Reaktion ·
-
bug needs triage pkg/translator/faro
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
open-telemetry/opentelemetry-collector-contrib#51484 · 1 Kommentar ·