All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Eygene Ryabinkin <rea-git@codelabs.ru>,
	Junio C Hamano <junkio@cox.net>, Alex Riesen <raa.lkml@gmail.com>
Subject: Re: Memory overrun in http-push.c
Date: Fri, 2 Mar 2007 19:42:57 +0000	[thread overview]
Message-ID: <200703021942.58780.andyparkins@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.63.0703022014410.22628@wbgn013.biozentrum.uni-wuerzburg.de>

On Friday 2007, March 02, Johannes Schindelin wrote:

> On Fri, 2 Mar 2007, Andy Parkins wrote:
> > Here's another similar idea: generating copyright lines.  Let's say
> > we want to copyright every source file - that means writing "(C)
> > Junio, (C) Johannes, etc" at the top of every file.  Wouldn't it be
> > nicer if we could put $Copyright$ in the file, then have some
> > git-blame-like machinery fill in the copyrights automatically based
> > on who's made contributions?
>
> That's a horrible idea. A typo fix is not copyrightable. You'd add
> these. An obious fix is not copyrightable. You'd add these cases,
> too.

Well, I wasn't actually suggesting that as a final solution, it might be 
that it's done by more than just line count, and that some clever bit 
of machinery measures real contribution.  That wasn't really the point.

> Besides, IMHO adding copyright should be a _concious_ act.

Well, IMHO, the concious act was the commital of a change.

A lot of your objection to this seems to be "IMHO".  Fine: you don't 
like keywords, you wouldn't be /forced/ to use them.  I can see a use 
for them.  I'm having a lot of trouble understanding why they are seen 
as inherently evil.  Difficult to implement, I would accept, 
impractical to make work in git would be fine; but not this hand wavery 
that there is no conceivable use for them.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

  reply	other threads:[~2007-03-02 19:46 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-28 15:15 Memory overrun in http-push.c Eygene Ryabinkin
2007-02-28 15:41 ` Andy Parkins
2007-02-28 15:42   ` Johannes Schindelin
2007-03-01  5:13   ` Eygene Ryabinkin
2007-03-01  8:15     ` Alex Riesen
2007-03-01  9:11       ` Eygene Ryabinkin
2007-03-01  9:21         ` Alex Riesen
2007-03-01 11:26           ` Eygene Ryabinkin
2007-03-01  9:32       ` Junio C Hamano
2007-03-01 10:04         ` Alex Riesen
2007-03-01 10:40         ` Andy Parkins
2007-03-01 12:00     ` Eygene Ryabinkin
2007-03-01 12:08       ` Junio C Hamano
2007-03-01 13:20         ` Eygene Ryabinkin
2007-03-01 17:11       ` Johannes Schindelin
2007-03-01 18:31         ` Andy Parkins
2007-03-01 18:41           ` Johannes Schindelin
2007-03-01 19:31             ` Andy Parkins
2007-03-01 20:43               ` Johannes Schindelin
2007-03-02 10:05                 ` Andy Parkins
2007-03-02 14:46                   ` Jakub Narebski
2007-03-02 15:22                     ` Andy Parkins
2007-03-02 19:16                   ` Johannes Schindelin
2007-03-02 19:42                     ` Andy Parkins [this message]
2007-03-04  8:17                   ` Daniel Barkalow
2007-03-04  8:31                     ` Junio C Hamano
2007-03-04  9:18                       ` Daniel Barkalow
2007-03-01 21:43         ` Alex Riesen
2007-03-01 21:54           ` Shawn O. Pearce
2007-03-01 17:52       ` Uwe Kleine-König
2007-03-02 14:38       ` Jakub Narebski
2007-03-02 15:17         ` Johannes Schindelin
2007-03-02 22:52           ` identifying blobs (was Re: Memory overrun in http-push.c) Junio C Hamano
2007-03-02 23:10             ` Linus Torvalds
2007-03-02 15:23         ` Memory overrun in http-push.c Andy Parkins
2007-03-02 15:30           ` Matthieu Moy
2007-03-02 15:48             ` Andy Parkins
2007-02-28 16:36 ` Florian Weimer
2007-03-01  5:19   ` Eygene Ryabinkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200703021942.58780.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=raa.lkml@gmail.com \
    --cc=rea-git@codelabs.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.