git에서 저작권 날짜 범위를 자동으로 업데이트 하시겠습니까?

필자는 2012 년에 10 일을 썼다. 많은 프로그래머들이 소스 파일의 맨 위에있는 저작권 문자열을 다음과 같이 편집하고있다.

// Copyright 2008, 2010-2012 Some Company Unlimited

버전 관리 시스템은 파일이 수정 된시기를 알고 있으므로 이러한 문자열을 쓰거나 다시 작성할 수 있습니다. 그래서 내 질문 : 각 파일에 대한 자식 로그를 검사하고 그와 비슷한 문자열을 출력 (또는 더 잘 삽입) 할 수있는 스크립트가 있습니까?

git을 사용하고 있기 때문에 주요 관심 사항이지만 다른 시스템에 해당 스크립트가 있는지 알려주십시오.

최신 정보:

이 작업을 수행하는 스크립트가 필요합니다.

작업 사본의 모든 소스 파일을 걷습니다.
기존 저작권 문자열을 찾고 연도를 식별합니다. 예 : 2007,2009-2011은 {2007, 2009, 2010, 2011}
언급되지 않은 해마다 1 월 1 일에서 12 월 31 일 사이 (또는 현재 연도 인 경우 오늘)를 비교하십시오. diff를 검사하고 저작권 문자열에 언급 할 가치가 있는지 결정
새로운 저작권 문자열을 삽입하십시오.

git copyright

— 용지 걸림
소스

내가 올바르게 이해하면 날짜는 선택 사항입니다. 그래도 좋은 질문입니다. +1.

— Maxpm

날짜가 법적으로 중요하지는 않지만 파일을 언제 만졌는지 보는 것은 흥미 롭습니다. 스크립트가 있으면 모든 소스 파일 에서이 줄을 정확하고 자동으로 설정하도록 실행할 수 있으며 이에 대해 더 이상 생각할 필요가 없습니다!

— paperjam

자동 생성 된 저작권 표시의 법적 중요성에 대해 궁금합니다. 업데이트 된 통지 자체는 저작권이 없으므로 새로운 창작물을 추가하지 않고 저작권에 대해 1 년 연장을 청구하고 있습니다.

— David Thornley

좋은 지적 @ 데이비드. 그러한 도구는 자체 커밋을 무시해야한다고 생각합니다. 또한 새로운 컨텐츠를 대표하지 않는 커밋 (예 : 텍스트 삭제, 작은 변경, 이름 변경, 재 포맷 등)을 무시하도록 구성 될 수 있습니다.

— paperjam

진짜 질문은 누군가가 지금부터 70/95/120 년 동안 코드를 관리 할 것인가?

— Nick T

답변:

TL; DR

걱정 마세요! 시간을 업데이트하지 않으면 프로젝트에 대한 저작권이 만료되지 않습니다! 당신은 안전합니다-그것은 그렇게 작동하지 않습니다.

긴 버전 :

저작권 표시의 모든 연도 번호가 범위가 아닌 저작권 시작을 나타내는 것으로 확신합니다. 연도를 추가하면 종료가 아니라 시작이 계속됨을 의미합니다. 새 컨텐츠 (예 : 새 모듈)를 추가하여 새 컨텐츠의 시작 연도를 나타내는 경우에 사용합니다. 선택 사항이지만 완전히 새로운 모듈이나 완전한 디자인 개조와 같은 큰 변화에 사용해야합니다.

저작권은 통지에서 지난해 이후 고정 된 수년 (국가의 법률에 따라 다름) 후에 만료되어야합니다.

따라서 소스 헤더를 바쁘게 업데이트 할 이유가 없습니다.

편집하다:

문제는 대개 실질적으로 충분한 변경 사항에는 완전히 새로운 소스 파일이나 이전 파일의 재 구현이 포함됩니다. 따라서 항상 새 소스 파일의 헤더에 현재 연도를 사용하는 한 괜찮습니다. 업데이트하기 위해 모든 단일 파일을 통과 할 필요가 없습니다. 실제로 수동 변경이 필요한 유일한 것은 라이센스 텍스트 자체 또는 readme 파일에 날짜 범위가있는 경우입니다.

면책 조항 : 나는 변호사가 아닌 프로그래머입니다.

— 고란 요빅
소스

파일을 크게 변경할 때마다 연도 / 확대 범위를 추가해야합니다. 그래서 raason이 있습니다. 문제는 자동이 아니어야한다는 것입니다 .git은 변경이 중요한 시점을 알 수 없습니다.

— herby

@ 허비 : 나는 명확하게 편집하고 내 답변에 대한 귀하의 의견에 대한 답변을 편집했습니다.

— Goran Jovic

IANAL 또는 AFAIK (저작권 만료 날짜)는 마지막 생존 한 작성자의 사망 날짜를 기준으로합니다. 창작 날짜는 누군가가 귀하의 작품에 대해 선행 기술을 주장 할 때만 중요합니다.

— tdammers

@tdammers : IANAL이지만 법적 개인이 저작권을 보유 할 수있는 국가의 IIRC는 생성 날짜에 따라 만료됩니다. 소프트웨어 저작권이 회사 또는 소프트웨어를 작성한 실제 직원이 보유하고 있는지 여부는 특정 관할권에 따라 다릅니다 (IIRC 미국 법에 따라 저작권이 할당되는 반면 대부분의 유럽 법률은 독점적 권리 만 허용하고 저작권은 여전히 물리적 저자가 보유 함) 작업 계약 (저작권은 가능할 때 할당 할 필요가 없습니다).

— Jan Hudec

각 파일에 대한 자식 로그를 검사하고 이와 비슷한 문자열을 출력 (또는 더 잘 삽입) 할 수있는 스크립트가 있습니까?

스크립트 자체는 아니지만 이 작업에 사용할 수있는 Git 기능 : 얼룩 / 청소 필터 쌍

— 게으른 오소리
소스

-2

아니요, git은 파일이 언제 수정되었는지 알 수 없습니다.

Git commit 객체는 특정 지점에서 모든 파일의 내용을 정의합니다. 같은 내용이 다른 커밋, 심지어 관련이없는 커밋에 쉽게 나타날 수 있습니다. 그중 하나를 더 중요하게 할 것은 없습니다. 따라서 대답이 모호 할 수도 있지만 종종 그렇지 않습니다.

— 얀 후덱
소스

흠 ... git은 내가 입력 할 때 날짜를 어떻게 알 수 git log있습니까?

— paperjam

@ paperjam : 커밋 이 생성 된 시점을 알고 있습니다. 를 입력 git log하면 커밋이 진행되므로 날짜를 알 수 있습니다. 그러나 어떤 커밋이 특정 버전의 파일을 도입했는지 알 수 없습니다. 둘 이상이있을 수 있습니다.

— Jan Hudec

Blob에 액세스 제어 비트를 저장하므로 해당 시점의 수정 날짜도 저장할 수 있습니다. 그러나 나는 확실하지 않다.

— Tamás Szelei

@ TamásSzelei : 아니요, blob은 정확히 단어 "blob", 줄 바꿈 및 내용입니다. 그게 다야. 이름조차 없습니다. 트리는 가리키는 Blob 및 하위 트리의 이름, 유형 및 실행 가능 비트를 갖습니다. 그러나 그것은 여전히 완전히 역사적입니다. 이것은 의도적이고 의도적 인 것입니다.

— Jan Hudec

여기에서 OP의 대답을 외삽 할 수도 있지만 릴리스 시점에서 중요한 것은 커밋이 이루어진 시점과 파일이 마지막으로 터치 된 시점이 아닌 유일한 시점이라고 생각합니다 . 커밋되지 않고 병합되지 않으면 놓지 않습니다. 그러므로 왜 git log --follow [filename] | grep -m 1 Date최신 날짜를 얻기에 충분할 만큼 간단한 일을 하는가?

— Spoike