Atualizar automaticamente o intervalo de datas de direitos autorais do git?

Enquanto escrevo, estamos dentro de 10 dias em 2012. Aposto que muitos programadores estão editando a cadeia de direitos autorais na parte superior de seus arquivos de origem para algo como:

// Copyright 2008, 2010-2012 Some Company Unlimited

Seu sistema de controle de versão sabe quando os arquivos foram modificados; portanto, com certeza ele pode ajudar a escrever ou reescrever essas strings. Então, minha pergunta: existe um script que pode examinar os logs do git para cada arquivo e gerar (ou melhor, inserir) uma string como essa?

Estou usando o git, pelo que é de interesse principal, mas deixe-me saber se esses scripts existem para outros sistemas.

Atualizar:

Precisamos de um script que faça isso:

Anda em todos os arquivos de origem em nossa cópia de trabalho
Localiza a cadeia de direitos autorais existente e identifica os anos, por exemplo, 2007,2009-2011 seria {2007, 2009, 2010, 2011}
Para cada ano não mencionado, difira entre 1 de janeiro e 31 de dezembro (ou hoje, se o ano atual). Examine o diff e decida se vale a pena mencionar na sequência de direitos autorais
Insira uma nova sequência de direitos autorais.

git copyright

— paperjam
fonte

Se bem entendi, a data é opcional de qualquer maneira. Boa pergunta, no entanto. +1.

— Maxpm

Sei que a data não é legalmente significativa, mas é interessante ver quando os arquivos foram tocados. Se houvesse um script que eu pudesse executar para definir essa linha com precisão e automaticamente em todos os arquivos de origem, não será necessário pensar mais sobre isso!

— usar o seguinte código

Fiquei pensando sobre o significado legal de um aviso de direitos autorais gerado automaticamente. O aviso atualizado em si não é protegido por direitos autorais, portanto, você está reivindicando uma extensão de 1 ano nos direitos autorais sem que novos trabalhos criativos sejam adicionados.

— David Thornley

Bom ponto @ David. Eu acho que qualquer ferramenta desse tipo teria que ignorar qualquer um de seus próprios commits. Talvez também pode ser configurado para ignorar commits que não tipificam novos conteúdos (por exemplo, supressão de texto, pequenas mudanças, renomeações, reformatação, etc.)

— paperjam

A verdadeira questão é: alguém se importará com o seu código daqui a 70/95/120 anos?

— Nick T

Respostas:

TL; DR

Não se preocupe! Seus direitos autorais sobre o projeto não expirarão se você não atualizar o ano a tempo! Você está seguro - não funciona dessa maneira.

Versão longa:

Tenho certeza de que todos os números de ano no aviso de direitos autorais indicam o início dos direitos autorais e não o intervalo. Se você adicionar um ano, significa a continuação do início, não do fim. Você o usará se adicionar novo conteúdo (como novos módulos) para indicar o ano inicial apenas para esse novo conteúdo. É opcional, mas deve ser usado para grandes mudanças, como módulos totalmente novos ou uma reforma completa no design.

Os direitos autorais devem expirar após um número fixo de anos (que depende das leis do seu país) após o último ano em seu aviso.

Portanto, não vejo motivo para atualizar os cabeçalhos de origem.

EDITAR:

O fato é que geralmente as mudanças que são substanciais o suficiente envolvem arquivos de origem completamente novos ou uma reimplementação dos antigos. Portanto, desde que você sempre use o ano atual nos cabeçalhos dos novos arquivos de origem, você estará bem. Não há necessidade de passar por todos os arquivos para fazer a atualização. Na verdade, a única coisa que requer uma alteração manual é se você tiver um período no próprio texto da licença ou no arquivo leia-me.

Disclaimer: Eu sou um programador, não um advogado.

— Goran Jovic
fonte

Você deve adicionar um intervalo de ano / ampliar sempre que fizer alterações substanciais em um arquivo. Então o raason está lá. O problema é que não deve ser automático - o git não pode dizer quando a mudança é substancial.

— Herby

@herby: Eu editei um esclarecimento e uma resposta ao seu comentário na minha resposta.

— Goran Jovic

IANAL também, mas AFAIK, a data de validade dos direitos autorais se baseia na data de falecimento do último autor sobrevivente. A data de criação é apenas interessante quando alguém reivindica a arte anterior no seu trabalho.

— tdammers

@tdammers: IANAL também, mas o IIRC em países onde as pessoas jurídicas podem ter direitos autorais; os direitos autorais mantidos por pessoa jurídica expiram com base na data de criação. Se os direitos autorais do software são detidos pela empresa ou pelos funcionários reais que os criaram dependem de uma jurisdição específica (a lei do IIRC nos EUA permite que os direitos autorais sejam atribuídos, enquanto a maioria das leis européias permite apenas direitos exclusivos, enquanto os direitos autorais ainda são detidos por autores físicos) e contrato de trabalho (os direitos autorais não precisam ser atribuídos quando podem).

— Jan Hudec

existe um script que possa examinar os logs do git para cada arquivo e gerar (ou melhor inserir) uma string como essa?

Não é um script em si, mas o recurso Git , que você pode usar para esta tarefa: par de filtro smudge / clean

— Lazy Badger
fonte

-2

Não, o git não sabe quando os arquivos foram modificados.

O objeto Git commit simplesmente define o conteúdo de todos os arquivos em um ponto específico. O mesmo conteúdo pode aparecer facilmente em outro commit, mesmo que não relacionado. Não há nada para tornar um deles mais importante. Portanto, a resposta pode ser ambígua, embora muitas vezes não seja.

— Jan Hudec
fonte

Hmmm ... Como o git sabe a data em que digito git log?

— usar o seguinte código

@paperjam: Ele sabe quando os commits foram criados. Quando você digita git log, ele segue os commits, então é claro que sabe a data deles. Mas pode não saber qual commit introduziu uma versão específica do arquivo, porque pode haver mais de um.

— Jan Hudec

Ele salva os bits de controle de acesso no blob, portanto, também pode salvar a data de modificação nesse momento. Mas eu não tenho certeza.

— Tamás Szelei

@ TamásSzelei: Não, blob é exatamente a palavra "blob", uma nova linha e o conteúdo. É isso aí. Nem mesmo um nome. Uma árvore tem o nome, o tipo e o bit executável dos blobs e subárvores para os quais aponta. Mas isso ainda é totalmente a-histórico. Isso é intencional e por design.

— Jan Hudec

Talvez eu esteja extrapolando a resposta do OP aqui, mas acho que a única coisa que importa, do ponto de vista da liberação, é quando o commit foi feito e não exatamente quando o arquivo foi tocado pela última vez. Simplificando, se não for confirmado e mesclado, ele não será lançado. Por isso, fazer algo tão simples quanto git log --follow [filename] | grep -m 1 Dateseria suficiente para obter a data mais recente.

— Spoike