Автоматично оновлювати діапазон дат авторських прав від git?

Коли я пишу, нам 10 днів до 2012 року. Б'юсь об заклад, що багато програмістів редагують рядок авторських прав у верхній частині вихідних файлів на щось подібне:

// Copyright 2008, 2010-2012 Some Company Unlimited

Ваша система контролю версій знає, коли файли були змінені настільки точно, це може допомогти написати або переписати ці рядки. Отже, моє запитання: чи існує сценарій, який може вивчити журнали git для кожного файлу та вивести (або краще вставити) такий рядок?

Я використовую git, тому це становить першочерговий інтерес, але повідомте мене, чи існують такі сценарії для інших систем.

Оновлення:

Нам потрібен сценарій, який робить це:

Зберігає всі вихідні файли в нашій робочій копії
Знаходить існуючий рядок авторських прав і визначає роки, наприклад, 2007,2009-2011 було б {2007, 2009, 2010, 2011}
Кожен рік, який не згадується, відрізняється від 1 січня до 31 грудня (або сьогодні, якщо поточний рік). Вивчіть відмінності та вирішіть, чи варто згадати в рядку авторських прав
Вставте новий рядок авторського права.

git copyright

— paperjam
джерело

Якщо я правильно розумію, дата все одно не є обов'язковою. Хороше питання, хоча. +1.

— Maxpm

Я знаю, що дата не є юридично важливою, але цікаво побачити, коли торкнулися файлів. Якщо був би сценарій, який я міг би запустити, щоб точно та автоматично встановити цей рядок у всіх вихідних файлах, тоді більше про це не потрібно думати!

— paperjam

Мене цікавить юридичне значення автоматично створеного повідомлення про авторські права. Саме оновлене повідомлення не може бути захищено авторським правом, тому ви вимагаєте продовження авторського права на 1 рік без додавання нових творчих робіт.

— Девід Торнлі

Хороший момент @David. Я думаю, будь-якому такому інструменту доведеться ігнорувати будь-які власні зобов'язання. Можливо, воно також може бути налаштоване на ігнорування комітетів, які не типізують новий вміст (наприклад, видалення тексту, невеликі зміни, перейменування, переформатування тощо)

— paperjam

Справжнє питання - чи буде хтось хвилюватись вашим кодом 70/95/120 років відтепер?

— Нік Т

Відповіді:

TL; DR

Не хвилюйтесь! Ваші авторські права на проект не закінчуються, якщо ви не оновили рік вчасно! Ви в безпеці - це не працює так.

Довга версія:

Я майже впевнений, що цілий рік у повідомленні про авторські права вказують на початок авторських прав, а не на діапазон. Якщо додати рік, це означає продовження початку, а не кінця. Ви використовуєте його, якщо додаєте новий вміст (наприклад, нові модулі), щоб вказати початковий рік лише для цього нового вмісту. Це необов’язково, але його слід використовувати для великих змін, як цілі нові модулі або повне перетворення дизайну.

Авторські права повинні закінчуватися через фіксовану кількість років (що залежить від законів у вашій країні) після останнього року у вашому повідомленні.

Тож я взагалі не бачу причини для ділового оновлення заголовків джерел.

Редагувати:

Вся справа в тому, що зазвичай досить істотні зміни включають абсолютно нові вихідні файли або повторну реалізацію старих. Отже, якщо ви завжди використовуєте поточний рік у заголовках нових вихідних файлів, у вас все добре. Немає необхідності проходити через кожен файл для оновлення. Насправді, єдине, що вимагає зміни вручну - це наявність діапазону дат у самому тексті ліцензії або у файлі readme.

Відмова: Я програміст, а не юрист.

— Горан Йович
джерело

Ви повинні додавати діапазон року / збільшення, коли ви вносите істотні зміни у файл, afaict. Значить, підступ є. Проблема в тому, що вона не повинна бути автоматичною - git не може визначити, коли зміна є істотною.

— herby

@herby: я відредагував уточнення та відповідь на ваш коментар у своїй відповіді.

— Горан Йович

IANAL також, але AFAIK, термін дії авторських прав заснований на даті смерті останнього автора, що залишився в живих. Дата створення представляє інтерес лише тоді, коли хтось претендує на попереднє мистецтво на вашу роботу.

— tdammers

@tdammers: IANAL також, але IIRC у країнах, де юридичні особи можуть володіти авторськими правами, авторське право, яке зберігається юридичною особою, закінчується за датою створення. Незалежно від того, чи належать авторські права на програмне забезпечення компанії або фактичні працівники, які її написали, залежить від конкретної юрисдикції (закон США IIRC дозволяє призначати саме авторське право, тоді як більшість європейських законів дозволяють виключні права, поки авторські права все ще зберігаються фізичними авторами) і договір про роботу (авторське право не повинно присвоюватися, коли воно може).

— Ян Худек

чи існує сценарій, який може вивчити журнали git для кожного файлу та вивести (або краще вставити) такий рядок?

Це не сценарій сам по собі, а функція Git , яку ви можете використовувати для цього завдання: розмазати / очистити фільтр-пару

— Ледачий борсук
джерело

-2

Ні, git не знає, коли файли були змінені.

Об'єкт Git commit просто визначить вміст усіх файлів у певній точці. Той самий вміст може легко відображатися в іншому комітеті, навіть не пов'язаному між собою. Немає чого зробити один з них важливішим. Тож відповідь може бути неоднозначною, хоча вона часто не дає.

— Ян Худець
джерело

Гммм ... Як Git дізнається дату під час введення git log?

— paperjam

@paperjam: Він знає , коли коммітов були створені. Коли ви набираєте git log, він виконує завдання, тому, звичайно, він знає їх дату. Але він може не знати, який фільтр представив конкретну версію файлу, оскільки їх може бути більше.

— Ян Худець

Він дійсно зберігає біти контролю доступу в краплі, тому може також зберегти дату модифікації в цій точці. Але я не впевнений.

— Tamás Szelei

@ TamásSzelei: Ні, blob - це саме слово "blob", новий рядок та зміст. Це воно. Навіть імені. Дерево має назву, тип та виконуваний біт для крапок та підрядів, на які вказує. Але це все-таки абсолютно історично. Це навмисно і задумом.

— Ян Худек

Я, можливо, екстраполюю відповідь ОП тут, але я думаю, що єдине, що має значення, з точки зору випуску, - це коли було зроблено фіксацію, а не саме тоді, коли файл востаннє торкався. Простіше кажучи, якщо він не вчинений і злитий, він не звільняється. Отже, чому робити щось так просто, як це git log --follow [filename] | grep -m 1 Dateбуло б достатньо, щоб отримати останню дату.

— Спікей