linux-kernel - Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 16 Aug 2007 13:08:05 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Kyle Moffett <mrmacman_g4@....com>
CC:	Satyam Sharma <satyam@...radead.org>,
	Al Viro <viro@....linux.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Joe Perches <joe@...ches.com>, git@...r.kernel.org,
	Junio C Hamano <gitster@...ox.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arjan van de Ven <arjan@...radead.org>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Mariusz Kozlowski <m.kozlowski@...land.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

On 08/16/2007 12:58 PM, Rene Herman wrote:

> On 08/15/2007 03:52 PM, Kyle Moffett wrote:

>> If you were going to do that I'd just suggest making git aware of the 
>> "user.*" extended attributes and having it save those into the git 
>> repo along with the permission data.
> 
> Am looking at it but am not so sure that's a very good idea. I guess 
> it'd be largely okay-ish to require the repo to be on a filesystem that 
> supports EAs for this feature to work, but keeping the attributes intact 
> over file system operations seems not all that easy (yet). Having not 
> used EAs before I may be missing something but my version of "cp" for 
> example (GNU coreutils 6.9) appears to not copy them. Nor do they seem 
> to survive a trip through GNU tar 1.16.1. EAs appear to not be very 
> useful unless every single tool supports them -- a repo should be 
> resistant against simple operations like that.
> 
> Googling around, I see subversion already has this and calls the 
> meta-data "properties" (svn propset/get and friends). It uses a few 
> properties itself, such as the svn:executable property (which I saw is 
> also the only permission bit git keeps) and svn:ignore, which serves the 
> same role as the .gitignore files for git. Both those would fit into 
> this scheme nicely for git as well, if git were to do something similar 
> and reserve for example the "git.*" namespace for internal use.
> 
> Junio (and others), do you have an opinion on this? If these properties 
> are versioned themselves such as in svn I believe it's a decidedly 
> non-trivial addition (and I'm a complete git newbie) but to me, they 
> look incredibly useful, both for the original "maintainers" properties 
> (and anyone else one would want to come up with such as summary 
> properties and author/license stuff) and even for git internal reasons 
> such as sketched above.
> 
> The git-blame thing as sketched before by Linus would never be able to 
> point out mailing lists, or general lists of "interested parties" for 
> example, but these properties can do anything...

The svn implemention is that a single property is free-form text. As such, I 
guess a property would be just another file, although one that only lives in 
the index and is linked from the file/directory it is a property of.

Perhaps that immediately suggests an implementation to someone already 
familiar with git internals?

Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/