Revisione strutturale
Il codice spostato e riformattato non appare più come rumore. I token modificati sono evidenziati nella loro struttura: un refactoring si legge per ciò che fa, non come migliaia di righe toccate.
Diff strutturali con Tree-sitter per oltre 60 linguaggi: TypeScript, Python, Rust, Go, Java e altri. Il codice spostato o riformattato non appare più come una modifica massiccia; i token modificati vengono evidenziati nella loro struttura. Se il motore non riesce ad analizzare un file, mostra la patch normale e segnala l’alternativa. La patch resta a un clic.
Una revisione deve distinguere cambiamenti di comportamento, simboli spostati e semplici modifiche di formato. La patch normale resta il riferimento; l’analisi semantica facilita l’esame di grandi refactoring.
FluxGit non promette un diff semantico completo per ogni linguaggio o file. Le viste semantiche sono in beta e devono indicare chiaramente l’alternativa testuale. Quando l’analisi semantica non è disponibile, si mostra il normale diff Git.
Il codice spostato e riformattato non appare più come rumore. I token modificati sono evidenziati nella loro struttura: un refactoring si legge per ciò che fa, non come migliaia di righe toccate.
Se il motore non riesce ad analizzare un file, la vista lo indica e mostra il normale diff Git. «Copy semantic diff» indica quanti file hanno analisi strutturale e quanti usano l’alternativa. Non viene inventato alcun riepilogo.
Quando un agente propone merge, rebase o reset, la scheda di approvazione apre un riepilogo strutturale e poi il diff per file, privilegiando la vista semantica. Se un file non è analizzabile, indica «Structural view unavailable - showing text diff».
I diff possono contenere codice sensibile. FluxGit li tratta come contesto locale dell’applicazione, salvo invio deliberato a un flusso IA o fornitore configurato, oppure condivisione di diagnostica con consenso.