Does graphify update consider Git working tree changes when updating the graph?

[andreastedile]

Specifically, if I have files that are:

• untracked
• modified but unstaged
• staged but uncommitted

and I run:

graphify update

what content is used to update the graph?

Will the graph update include those files and their current contents from the working directory, or does it only use content from committed Git state?

This affects whether local, uncommitted content can become part of the graph, which is important for predictability and privacy/safety of local changes.

[starkmarkus]

This is an important distinction, especially for privacy and reproducibility.

I would expect one of two possible behaviors:

• filesystem-based update: reads the current working tree, including modified and possibly untracked files
• git-based update: reads only committed/tracked Git state, or a specific commit/ref

For safety, I do not think users should have to guess which one graphify update uses. The command should ideally document this explicitly, because including uncommitted local files can accidentally add private work-in-progress content, secrets, notes, or generated files to the graph.

The behavior I would personally expect from a safe default is:

• tracked committed files are included
• modified but uncommitted files are either excluded by default or clearly warned about
• untracked files are excluded unless explicitly requested
• staged-but-uncommitted files are treated consistently and documented
• there is a flag for the other mode, for example --working-tree or --committed-only

If Graphify currently reads from disk, then I think graphify update should print a warning when the working tree is dirty, or at least provide a --committed-only / --ignore-untracked option.

So the core question is: does graphify update index the Git commit state, or does it index the current filesystem snapshot? Either behavior can be valid, but it should be explicit because the privacy implications are quite different.