On 02/10/2015 08:12 PM, Junio C Hamano wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> writes:
>
>> On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote:
>>
>>> +# Copyright (c) 2014 Michael Haggerty <mhagger@xxxxxxxxxxxx>
>>
>> What is the projects stance on copyright lines?
>
> I do not think we have a strong one.
>
>> I've seen files (most of them from the beginning) having some copyright lines,
>> other files (often introduced way later) not having them, "because
>> we're git and have
>> history, so we know who did it".
>
> I personally agree with that statement. Also, a copyright notice
> per file is often added when a new file is added, but that ends up
> giving false sense of "ownership" to everybody else down the line
> even after the file has been extensively modified. It's not like
> Michael solely owns all lines in this file in later versions. And
> even if people added their name at the top every time they make any
> change, their names tend to stay even when their contributions are
> later completely rewritten or removed.
>
> In a sense, my agreement with your statement is stronger than "Yes,
> Git can tell us who did what anyway". What we can find in the
> history is the sole source of truth, and in-file copyright notice is
> misleading. You do not even have to have one in the Berne signatory
> nations anyway.
I only put a copyright notice there because I thought it was standard
practice. I think it is ugly and would rather do without it, even aside
from the practical problems that Junio mentioned.
On the other hand, there's this [1] and this [2] from the FSF, which
recommend a copyright blurb at the beginning of every source file.
Though actually the recommendation is to include a GPL blurb too, not
just a naked copyright line like I used. But I get the feeling that the
FSF's recommendation is more for ideological than for legal reasons.
If I don't hear anything else, I'll delete the copyright line in the reroll.
>> The tests themselves look fine.
>>
>> Is there a reason you did not append the tests in 7509 ?
>
> Hmph.
I don't know what "Hmph" means in this context.
The description for t7509 is "git commit --reset-author", which doesn't
seem to describe the new tests.
There are also
t7500 "git commit / Tests for selected commit options"
t7501 "git commit"
t7502 "git commit porcelain-ish"
I suppose the new tests could go in any of these. But since the tests
are thematically a bit unusual (dealing with races rather than testing
command-line options) and they start with an orphan commit, I thought it
would be just as easy to put them in their own file to make it clear
that they are independent.
I really don't care either way.
Michael
[1] http://www.gnu.org/licenses/gpl-howto.html
[2] http://www.gnu.org/licenses/gpl-faq.html#NoticeInSourceFile
--
Michael Haggerty
mhagger@xxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html