Gestire l'espansione delle parole chiave SVN con git-svn

Question

Recentemente ho chiesto informazioni espansione delle parole chiave in Git e sono disposto ad accettare il progetto di non supportare realmente questa idea in Git.

Nel bene e nel male, il progetto su cui sto lavorando al momento richiede l'espansione delle parole chiave SVN in questo modo:

svn propset svn:keywords "Id" expl3.dtx

per mantenere aggiornata questa stringa:

$Id: expl3.dtx 803 2008-09-11 14:01:58Z will $

Ma mi piacerebbe molto usare Git per eseguire il controllo della versione.Sfortunatamente, git-svn non lo supporta, secondo i documenti:

"Ignoriamo tutte le proprietà SVN tranne svn:executable"

Ma non sembra troppo complicato far sì che queste parole chiave vengano emulate da un paio di hook pre/post commit.Sono la prima persona a volerlo?Qualcuno ha del codice per farlo?

Answer 1

Cosa sta succedendo qui:Git è ottimizzato per passare da un ramo all'altro il più rapidamente possibile.In particolare, git checkout è progettato per non toccare alcun file identico in entrambi i rami.

Sfortunatamente, la sostituzione delle parole chiave RCS interrompe questo problema.Ad esempio, utilizzando $Date$ richiederebbe git checkout per toccare ogni file nell'albero quando si cambia ramo.Per un repository delle dimensioni del kernel Linux, questo porterebbe tutto a una brusca frenata.

In generale, la soluzione migliore è taggare almeno una versione:

$ git tag v0.5.whatever

...e poi chiama il seguente comando dal tuo Makefile:

$ git describe --tags
v0.5.15.1-6-g61cde1d

Qui, git mi sta dicendo che sto lavorando su un commit anonimo della versione 6 precedente alla v0.5.15.1, con un hash SHA1 che inizia con g61cde1d.Se inserisci l'output di questo comando in a *.h file da qualche parte, sei a posto e non avrai problemi a collegare il software rilasciato al codice sorgente.Questo è il modo preferito di fare le cose.

Se non puoi evitare di utilizzare le parole chiave RCS, potresti iniziare con queste spiegazione di Lars Hjemli.Fondamentalmente, $Id$ è abbastanza semplice e tu se lo stai utilizzando git archive, puoi anche usare $Format$.

Ma, se non puoi assolutamente evitare le parole chiave RCS, quanto segue dovrebbe aiutarti a iniziare:

git config filter.rcs-keyword.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'
git config filter.rcs-keyword.smudge 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date: `date`\\\$/"'

echo '$Date$' > test.html
echo 'test.html filter=rcs-keyword' >> .gitattributes
git add test.html .gitattributes
git commit -m "Experimental RCS keyword support for git"

rm test.html
git checkout test.html
cat test.html

Sul mio sistema, ottengo:

$Date: Tue Sep 16 10:15:02 EDT 2008$

Se hai problemi a far uscire la shell nel file smudge E clean comandi per funzionare, basta scrivere i propri script Perl rispettivamente per espandere e rimuovere le parole chiave RCS e utilizzare tali script come filtro.

Nota che tu Veramente non voglio farlo per più file del necessario, altrimenti git perderà gran parte della sua velocità.

Answer 2

Sfortunatamente, la sostituzione delle parole chiave RCS rompe questo.Ad esempio, l'utilizzo di $ Date $ richiederebbe il checkout Git per toccare ogni file nell'albero quando si commuta le filiali.

Quello non è vero.$Data$ ecc.espandere al valore valido al momento del check-in.In ogni caso è molto più utile.Quindi non cambia in altre revisioni o rami, a meno che il file non venga effettivamente riarchiviato.Dal manuale RCS:

   $Date$ The  date  and  time the revision was checked in.  With -zzone a
          numeric time zone offset is appended;  otherwise,  the  date  is
          UTC.

Ciò significa anche che la risposta suggerita sopra, con il filtro rcs-keyword.smudge, non è corretta.Inserisce l'ora/data del checkout o qualunque cosa ne provochi l'esecuzione.

Answer 3

Ecco un progetto di esempio contenente la configurazione e il codice di filtro necessari per aggiungere il supporto per le parole chiave RCS a un progetto git:

https://github.com/turon/git-rcs-keywords

Non è così semplice da configurare come si vorrebbe, ma sembra funzionare.Utilizza una coppia di filtri sbavatura/pulizia scritta in perl (simile a quanto descritto nella risposta di emk) e sì, toccherà tutti i file con le estensioni impostate in .gitattributes, generalmente rallentando un po' le cose.

Answer 4

Potresti impostare l'attributo ident sui tuoi file, ma ciò produrrebbe stringhe come

$Id: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef$

Dove deadbeef... è lo sha1 del blob corrispondente a quel file.Se hai davvero bisogno dell'espansione della parola chiave e ne hai bisogno nel repository git (al contrario di un archivio esportato), penso che dovrai seguire il ident gitattribute con uno script personalizzato che esegue l'espansione per te.Il problema con l'utilizzo del solo hook è che il file nell'albero di lavoro non corrisponderebbe all'indice e git penserebbe che sia stato modificato.