Version control awareness

[ghost]

Hello,

How can I make use of stack graphs in a version control-aware manner?

Let's say, I have a code repository from version control (git).
In each git commit, there are files that get created, modified and deleted.
How do I use stack graphs in a way such that it is aware of such changes?

e.g.:

1. I create a per-file index for each version of a file

2. I query indices by lazy loading each version (how?)

[hendrikvanantwerpen]

Hi! The library is certainly designed to fit an incremental model compatible with version control. However, there is no provided orchestration for that. Let me elaborate.

The overall idea is along the lines that you suggest.

1. For each blob in a commit, construct a stack graph and compute partial paths. Store these.

2. Resolve references using path stitching. The path stitcher is phased, and the result of the previous phase can be used to lazy load partial paths that may be relevant for the next phase.

This approach becomes nicely incremental when the results from (1) are stored based on the Git blob oid. If a blob doesn't change from one commit to the next, its blob oid will be the same, and the previous data can be used as-is. (Caveat: this is only true if the constructed stack graph only depends on the file content. Otherwise, the key should reflect all elements that went into the process. The principle stays the same, but incrementality may suffer.)

We are currently doing some work on the tree-sitter-stack-graphs CLI that includes the possibility to store and load index data. It is filesystem based though, but depending on your exact requirements you may be able to either reuse some of that code directly, or see the above idea implemented for inspiration.

[ghost]

Thanks. This answers my question.