Add repository-wide commit search across branches
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
Línea de trabajo
Empieza leyendo las implementaciones existentes de las herramientas search_commits y list_commits y sus llamadas a la API de GitHub. Comprueba si la API admite la búsqueda de commits en todo el repositorio con filtros de autor y fecha, y después identifica el diseño adecuado de la herramienta y las pruebas correspondientes. Se considera completado cuando se devuelven los commits coincidentes en ramas que no son la predeterminada, con paginación y metadatos útiles de SHA o ref.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- Go
- Estrellas
- 33.1k
- Forks
- 5k
- Merge medio
- 2 d 1 h
- PR fusionados (30 d)
- 25
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de github/github-mcp-server
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
github/github-mcp-server#3235 ·
-
enhancement
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
github/github-mcp-server#3042 · 2 comentarios ·
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
github/github-mcp-server#3032 · 1 reacción ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
github/github-mcp-server#2803 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
github/github-mcp-server#2740 ·
Todos los issues de github/github-mcp-server
Issues similares
-
textual definition
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
geneontology/go-ontology#32653 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
-
needs design
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Priority/High ready-for-agent Severity/Major Type/Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100