Aggiorna automaticamente l'intervallo di date del copyright da git?

Mentre scrivo, siamo passati 10 giorni nel 2012. Scommetto che molti programmatori stanno modificando la stringa di copyright nella parte superiore dei loro file sorgente in qualcosa del tipo:

// Copyright 2008, 2010-2012 Some Company Unlimited

Il tuo sistema di controllo della versione sa quando i file sono stati modificati in modo così sicuro che può aiutare a scrivere o riscrivere queste stringhe. Quindi la mia domanda: esiste uno script che può esaminare i log git per ogni file e produrre (o meglio inserire) una stringa del genere?

Sto usando git quindi questo è di primario interesse ma fammi sapere se tali script esistono per altri sistemi.

Aggiornare:

Abbiamo bisogno di uno script che faccia questo:

Cammina tutti i file di origine nella nostra copia di lavoro
Individua la stringa di copyright esistente e identifica gli anni, ad esempio 2007.2009-2011 sarebbe {2007, 2009, 2010, 2011}
Per ogni anno non menzionato, diff tra il 1 ° gennaio e il 31 dicembre (o oggi se l'anno in corso). Esamina diff e decidi se è degno di menzione nella stringa di copyright
Inserisci una nuova stringa di copyright.

git copyright

— paperjam
fonte

Se ho capito bene, la data è comunque facoltativa. Buona domanda, comunque. +1.

— Max.

So che la data non è giuridicamente significativa ma è interessante vedere quando i file sono stati toccati. Se ci fosse uno script che potrei eseguire per impostare questa riga in modo accurato e automatico su tutti i file di origine, non è necessario pensarci più!

— paperjam,

Mi sono chiesto quale sia il significato legale di un avviso sul copyright generato automaticamente. L'avviso aggiornato non è protetto da copyright, quindi stai richiedendo un'estensione di 1 anno sul copyright senza l'aggiunta di nuove opere creative.

— David Thornley,

Buon punto @ David. Immagino che uno di questi strumenti dovrebbe ignorare qualsiasi suo proprio commit. Forse potrebbe anche essere configurato per ignorare i commit che non tipizzano nuovi contenuti (ad es. Cancellazione del testo, piccole modifiche, rinominazioni, riformattazioni, ecc.)

— paperjam

La vera domanda è: a qualcuno interesserà il tuo codice tra 70/95/120 anni da adesso?

— Nick T

Risposte:

TL; DR

Non ti preoccupare! Il tuo copyright sul progetto non scadrà se non hai aggiornato l'anno in tempo! Sei al sicuro, non funziona così.

Versione lunga:

Sono abbastanza sicuro che tutti i numeri dell'anno nella nota sul copyright indicano l'inizio del copyright e non l'intervallo. Se aggiungi un anno significa che la continuazione dell'inizio, non della fine. Lo usi se aggiungi nuovi contenuti (come i nuovi moduli) per indicare l'anno di inizio solo per quel nuovo contenuto. È facoltativo, ma dovrebbe essere utilizzato per grandi cambiamenti, come moduli completamente nuovi o un restyling completo del design.

Il copyright dovrebbe scadere dopo un numero fisso di anni (che dipende dalle leggi del tuo paese) dopo l'ultimo anno nella tua notifica.

Quindi, non vedo alcun motivo per aggiornare intensamente le intestazioni dei sorgenti.

MODIFICARE:

Il fatto è che di solito i cambiamenti che sono abbastanza sostanziali coinvolgono file sorgente completamente nuovi o una reimplementazione di quelli vecchi. Quindi, purché utilizzi sempre l'anno corrente nelle intestazioni dei nuovi file di origine, stai bene. Non è necessario passare attraverso ogni singolo file per effettuare l'aggiornamento. In realtà, l'unica cosa che richiede una modifica manuale è se hai un intervallo di date nel testo della licenza stessa o nel file readme.

Disclaimer: sono un programmatore, non un avvocato.

— Goran Jovic
fonte

È necessario aggiungere un intervallo anno / ingrandimento ogni volta che si apportano modifiche sostanziali a un file, afaict. Quindi il raason è lì. Il problema è che non dovrebbe essere automatico - git non può dire quando il cambiamento è sostanziale.

— citato dal

@herby: ho modificato un chiarimento e una risposta al tuo commento nella mia risposta.

— Goran Jovic,

Anche IANAL, ma AFAIK, la data di scadenza del copyright si basa sulla data di morte dell'ultimo autore sopravvissuto. La data di creazione è interessante solo quando qualcuno rivendica l'arte nota sul tuo lavoro.

— martedì 18

@tdammers: IANAL, ma IIRC nei paesi in cui le persone giuridiche possono detenere il copyright scade un copyright detenuto dalla persona giuridica in base alla data di creazione. Se il copyright per il software è detenuto dalla società o dai dipendenti effettivi che lo hanno scritto dipende da una particolare giurisdizione (la legge statunitense IIRC consente di assegnare il copyright stesso mentre la maggior parte delle leggi europee consente solo diritti esclusivi mentre il copyright è ancora detenuto da autori fisici) e contratto di lavoro (il diritto d'autore non deve essere assegnato quando può).

— Jan Hudec,

c'è uno script che può esaminare i log git per ogni file e produrre (o meglio inserire) una stringa del genere?

Non è uno script di per sé, ma la funzionalità Git , che puoi utilizzare per questa attività: coppia di filtri sbavatura / pulizia

— Tasso pigro
fonte

-2

No, git non sa quando i file sono stati modificati.

L'oggetto commit Git definisce semplicemente il contenuto di tutti i file in un punto specifico. Lo stesso contenuto può facilmente apparire in un altro commit, anche se non correlato. Non c'è nulla per renderne uno più importante. Quindi la risposta potrebbe essere ambigua, sebbene spesso non lo sia.

— Jan Hudec
fonte

Hmmm ... Come fa Git a sapere la data in cui scrivo git log?

— paperjam,

@paperjam: sa quando sono stati creati i commit . Quando digiti git log, accompagna i commit, quindi ovviamente conosce la loro data. Ma potrebbe non sapere quale commit abbia introdotto una particolare versione del file, perché potrebbe essercene più di una.

— Jan Hudec,

Salva i bit di controllo di accesso nel BLOB, quindi potrebbe anche salvare la data di modifica in quel punto. Ma non sono sicuro.

— Tamás Szelei,

@ TamásSzelei: No, blob è esattamente la parola "blob", una nuova riga e il contenuto. Questo è tutto. Neanche un nome. Un albero ha il nome, il tipo e il bit eseguibile per i BLOB e i sottoalberi a cui punta. Ma è ancora totalmente antistorico. Questo è intenzionale e di progettazione.

— Jan Hudec,

Potrei estrapolare qui la risposta del PO, ma penso che l'unica cosa che conta, dal punto di vista del rilascio, sia quando è stato effettuato il commit e non esattamente quando è stato toccato l'ultimo file. In poche parole, se non viene commesso e unito, non verrà rilasciato. Quindi perché fare qualcosa di semplice come git log --follow [filename] | grep -m 1 Datesarebbe sufficiente per ottenere l'ultima data.

— Spoike,