2013-07-20 16 views
9

È possibile ricostruire una cronologia parola per parola nel controllo di versione? Idealmente, mi piacerebbe fare qualcosa di simile a 1) Indico la gamma di linee di interesse, 2) il programma calcola i numeri di riga corrispondenti nelle versioni precedenti, poiché il codice spesso si spostava in alto o in basso tra le versioni (potenzialmente limitando la gamma di versioni, diciamo dalla revisione 19, o da una settimana fa), 3) stampa una cronologia parola per parola, sia le versioni modificate per ultimi gruppi di parole, sia gli autori con cui i gruppi di parole sono stati modificati. Quindi è un po 'come svn blame o git blame a livello di parola per parola.Word-by-word biascicare/annotare nel controllo di versione?

In caso contrario, ci sono strumenti che possono fare # 1 e # 2 sopra? Cioè, 1) indico la gamma di linee di interesse, 2) il programma calcola i numeri di riga corrispondenti nelle versioni precedenti, 3) il programma stamperebbe la cronologia di queste righe (quando c'erano cambiamenti).

O svn o git sarebbe davvero utile per me.

+1

parola per parola! Io non la penso così, le tracce di git cambiano riga dopo riga. Stai cercando di usare git per gli scrittori? per i programmatori non penso che questo livello di colpa non sia richiesto. –

+0

Sì, sto provando a farlo su un documento LaTex, almeno al momento. Tuttavia non ha bisogno di essere qualcosa di integrato per git. Immagino che un programma esterno a git in grado di leggere la cronologia git possa fare anche questo. –

+3

@JeslyVarghese: Git tiene traccia dell'istantanea delle modifiche per istantanea. Il formato basato sulla linea è calcolato al volo e sarebbe anche possibile avere un formato basato su parole. – nosid

risposta

1

Ho cercato qualcosa di simile e ho finito per hackerare la mia soluzione. Lo si può trovare qui:

https://github.com/d33tah/wordblame

Fondamentalmente, si crea una nuova directory di repository in cui tutti gli spazi sono sostituiti da una nuova riga e stringa univoca segnalando che c'era uno spazio. Quindi, "git blame" viene eseguito e il risultato viene reinterpretato.