Tự động cập nhật phạm vi ngày bản quyền từ git?

Khi tôi viết, chúng tôi còn 10 ngày nữa vào năm 2012. Tôi cá rằng nhiều lập trình viên đang chỉnh sửa chuỗi bản quyền ở đầu các tệp nguồn của họ thành một cái gì đó như:

// Copyright 2008, 2010-2012 Some Company Unlimited

Hệ thống kiểm soát phiên bản của bạn biết khi nào các tệp được sửa đổi, vì vậy chắc chắn nó có thể giúp ghi hoặc viết lại các chuỗi này. Vì vậy, câu hỏi của tôi: có một kịch bản có thể kiểm tra nhật ký git cho mỗi tệp và đầu ra (hoặc chèn tốt hơn) một chuỗi như vậy về?

Tôi đang sử dụng git vì vậy đó là mối quan tâm chính nhưng hãy cho tôi biết nếu các tập lệnh như vậy tồn tại cho các hệ thống khác.

Cập nhật:

Chúng tôi cần một kịch bản thực hiện điều này:

Đi bộ tất cả các tệp nguồn trong bản sao làm việc của chúng tôi
Định vị chuỗi bản quyền hiện tại và xác định các năm, ví dụ: 2007,2009-2011 sẽ là {2007, 2009, 2010, 2011}
Đối với mỗi năm không được đề cập, khác nhau giữa ngày 1 tháng 1 và ngày 31 tháng 12 (hoặc hôm nay nếu năm hiện tại). Kiểm tra khác biệt và quyết định xem nó có xứng đáng được đề cập trong chuỗi bản quyền không
Chèn chuỗi bản quyền mới.

git copyright

— kẹt giấy
nguồn

Nếu tôi hiểu chính xác, ngày nào là tùy chọn. Câu hỏi hay, mặc dù. +1.

— Tối đa

Tôi biết ngày không có ý nghĩa về mặt pháp lý nhưng thật thú vị khi xem các tập tin được chạm vào. Nếu có một tập lệnh tôi có thể chạy để đặt dòng này một cách chính xác và tự động trên tất cả các tệp nguồn thì không cần phải suy nghĩ thêm về điều này!

— paperjam

Tôi đã tự hỏi về ý nghĩa pháp lý của một thông báo bản quyền được tạo tự động. Bản thân thông báo cập nhật không có bản quyền, vì vậy bạn đang yêu cầu gia hạn 1 năm về bản quyền mà không cần thêm tác phẩm sáng tạo mới.

— David Thornley

Điểm tốt @David. Tôi đoán bất kỳ công cụ như vậy sẽ phải bỏ qua bất kỳ cam kết riêng của nó. Có lẽ nó cũng có thể được cấu hình để bỏ qua các cam kết không đánh máy nội dung mới (ví dụ xóa văn bản, thay đổi nhỏ, đổi tên, cải tổ, v.v.)

— paperjam

Câu hỏi thực sự là có ai quan tâm đến mã của bạn 70/95/120 năm nữa không?

— Nick T

Câu trả lời:

TL; DR

Đừng lo lắng! Bản quyền của bạn đối với dự án sẽ không hết hạn nếu bạn không cập nhật kịp năm! Bạn an toàn - nó không hoạt động theo cách đó.

Phiên bản dài:

Tôi khá chắc chắn rằng tất cả các số năm trong thông báo bản quyền cho biết bắt đầu bản quyền không phải là phạm vi. Nếu bạn thêm một năm, điều đó có nghĩa là sự tiếp tục bắt đầu, không kết thúc. Bạn sử dụng nó nếu bạn thêm nội dung mới (như các mô-đun mới) để chỉ năm bắt đầu cho nội dung mới đó. Nó là tùy chọn nhưng nên được sử dụng cho các thay đổi lớn, như toàn bộ mô-đun mới hoặc thay đổi thiết kế hoàn chỉnh.

Bản quyền sẽ hết hạn sau số năm cố định (phụ thuộc vào luật pháp tại quốc gia của bạn) sau năm cuối cùng trong thông báo của bạn.

Vì vậy, tôi không thấy một lý do nào để bận rộn cập nhật tiêu đề nguồn cả.

BIÊN TẬP:

Vấn đề là thường thay đổi đủ lớn liên quan đến các tệp nguồn hoàn toàn mới hoặc triển khai lại các tệp cũ. Vì vậy, miễn là bạn luôn sử dụng năm hiện tại trong các tiêu đề của tệp nguồn mới thì bạn vẫn ổn. Không cần bất cứ điều gì để đi qua mỗi tệp duy nhất để thực hiện cập nhật. Trên thực tế, điều duy nhất yêu cầu thay đổi thủ công là nếu bạn có phạm vi ngày trong chính văn bản giấy phép hoặc trong tệp readme.

Tuyên bố miễn trừ trách nhiệm: Tôi là một lập trình viên, không phải luật sư.

— Goran Jovic
nguồn

Bạn nên thêm một năm / phạm vi phóng to bất cứ khi nào bạn thay đổi đáng kể đến một tập tin, afaict. Vì vậy, raason là ở đó. Vấn đề là, nó không nên tự động - git không thể biết khi nào thay đổi là đáng kể.

— Herby

@herby: Tôi đã chỉnh sửa trong một làm rõ và trả lời nhận xét của bạn trong câu trả lời của tôi.

— Goran Jovic

IANAL cũng vậy, nhưng AFAIK, ngày hết hạn bản quyền dựa trên ngày chết của tác giả cuối cùng còn sống. Ngày sáng tạo chỉ được quan tâm khi ai đó tuyên bố nghệ thuật trước về tác phẩm của bạn.

— tdammers

@tdammers: IANAL, nhưng IIRC ở các quốc gia nơi pháp nhân có thể giữ bản quyền bản quyền do pháp nhân nắm giữ hết hạn dựa trên ngày tạo. Việc bản quyền cho phần mềm được nắm giữ bởi công ty hay nhân viên thực tế đã viết nó tùy thuộc vào quyền tài phán cụ thể (luật IIRC của Hoa Kỳ cho phép bản quyền được chỉ định trong khi hầu hết luật pháp châu Âu chỉ cho phép quyền độc quyền trong khi bản quyền vẫn được giữ bởi các tác giả vật lý) và thỏa thuận công việc (bản quyền không phải được chỉ định khi có thể).

— Jan Hudec

Có tập lệnh nào có thể kiểm tra nhật ký git cho mỗi tệp và đầu ra (hoặc chèn tốt hơn) một chuỗi như thế không?

Đây không phải là tập lệnh mỗi lần, mà là tính năng Git , mà bạn có thể sử dụng cho tác vụ này: cặp lọc smudge / clean

— Lười biếng
nguồn

-2

Không, git không biết khi nào tệp được sửa đổi.

Đối tượng cam kết Git chỉ đơn giản là xác định nội dung của tất cả các tệp tại điểm cụ thể. Nội dung tương tự có thể dễ dàng xuất hiện trong một cam kết khác, thậm chí không liên quan. Không có gì để làm cho một trong số họ quan trọng hơn. Vì vậy, câu trả lời có thể mơ hồ, mặc dù nó thường không.

— Jan Hudec
nguồn

Hmmm ... Làm thế nào để git biết ngày khi tôi gõ git log?

— paperjam

@apersjam: Nó biết khi nào các cam kết được tạo. Khi bạn gõ git log, nó đi bộ các cam kết, vì vậy tất nhiên nó biết ngày của họ. Nhưng nó có thể không biết cam kết nào đã giới thiệu phiên bản cụ thể của tệp, bởi vì có thể có nhiều hơn một.

— Jan Hudec

Nó không lưu các bit điều khiển truy cập trong blob, vì vậy nó cũng có thể lưu ngày sửa đổi tại thời điểm đó. Nhưng tôi không chắc lắm.

— Tamás Szelei

@ TamásSzelei: Không, blob chính xác là từ "blob", một dòng mới và nội dung. Đó là nó. Thậm chí không có tên. Một cây có tên, loại và bit thực thi cho các đốm màu và phụ nó chỉ vào. Nhưng đó vẫn hoàn toàn là lịch sử. Đây là cố ý và theo thiết kế.

— Jan Hudec

Tôi có thể ngoại suy câu trả lời của OP ở đây nhưng tôi nghĩ điều duy nhất quan trọng, từ quan điểm phát hành, là khi cam kết được thực hiện và không chính xác khi tập tin được chạm lần cuối. Đơn giản chỉ cần đặt nếu nó không được cam kết và sáp nhập thì nó sẽ không được phát hành. Do đó tại sao làm một cái gì đó đơn giản như git log --follow [filename] | grep -m 1 Dateđủ để có được ngày mới nhất.

— Spoike