feat: cache Graphify context outside the repository
Los mantenedores suelen responder en 1 día
@hiyouwhatsapp ya está trabajando en esto.
Desde el 18/10/2026.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- git, python
- Área
- developer-experience, devtools
Línea de trabajo
Start by reading the existing --update workflow and locating how graphify-out/ is created, discovered, and reused. Define how a repository is identified in ~/.graphify/projects/<repository>/, how branch or path changes are detected, and how the existing graph is safely reused after a reset; done means the behavior is specified and tested for repository syncs and missing local output.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I work on multiple projects where main changes frequently.
My usual workflow looks like this:
- Generate a Graphify map of the repository.
- Use
graph.json,GRAPH_REPORT.md, and the visualization as context for my coding agent. - Before starting another contribution, sync my local branch with the latest upstream
main. - Continue working from the updated codebase.
The problem is that Graphify's generated files are local-only and usually ignored by Git. In some Git workflows, such as resetting or cleaning the local repository while syncing with upstream, this local Graphify context can be removed.
I then have to generate the graph again.
Graphify already supports --update, which is useful when the existing graph is still available. The problem is when the local graph itself is lost during repository maintenance.
Would it make sense for Graphify to support storing its local graph outside the repository?
For example:
~/.graphify/projects/<repository>/
The repository could then reference that local graph instead of depending entirely on graphify-out/ inside the working tree.
This could allow a workflow like:
clone/sync repository
↓
Graphify finds the existing local graph
↓
detect changed files
↓
update only what changed
Instead of:
clone/sync repository
↓
local Graphify output is gone
↓
build the project graph again
The exact implementation could be different. The main idea is simply to make Graphify's local knowledge persistent across branch resets, upstream syncs, or other Git operations that replace or clean the working tree.
This would be especially useful for contributors working on fast-moving repositories, where pulling or resetting to the latest upstream branch happens frequently.
Is there already a recommended workflow for this, or would persistent repository-level local storage be useful?
- Lenguaje dominante
- Python
- Estrellas
- 124k
- Forks
- 11.9k
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
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 Graphify-Labs/graphify
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Graphify-Labs/graphify#4831 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 75/100
Graphify-Labs/graphify#4829 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
hooks: last-resort `python3` probe launches the Microsoft Store redirector on Windows (visible console flash, exit 9009)Posiblemente ocupada @Deepjyoti-Sarmah la tomó hace 8 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Graphify-Labs/graphify#4563 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
GRAPHIFY_DISABLE_THINKING is ignored by the claude backend, so thinking eats max_tokens and extraction truncatesPosiblemente ocupada @bercedev la tomó hace 9 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 69/100
Graphify-Labs/graphify#4546 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
--update runbook: graph.json backup instruction comes after the diff that needs it, so the graph diff never runsPosiblemente ocupada @sunildivakar96-cpu la tomó hace 10 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Graphify-Labs/graphify#4539 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de Graphify-Labs/graphify
Issues similares
-
filesystem: `file://C:/...` bucket_url is read as a UNC share named `C:` and silently lists no filesAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
comp/desktop desktop/shell os/windows P3 tool/file type/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
NousResearch/hermes-agent#145928 ·
Los mantenedores suelen responder en 1 día
-
integration:coding-agents
Dificultad 1/5 Menos de una hora Aptitud para principiantes 83/100
vectorize-io/hindsight#6151 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
FormalLanguageConstrainedPathQuerying/FLPQ_Data#174 ·
Los mantenedores suelen responder en 1 día
-
[VLM] granite_vision preset produces empty output and runs ~3× slower with Granite Vision 3.3-2B than with Granite Vision 4.1-4BPosiblemente ocupada @prassu017 la tomó hoy. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
docling-project/docling#5068 · 4 comentarios ·
Los mantenedores suelen responder en 1 día