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 12:58:19 +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/15/2007 03:52 PM, Kyle Moffett wrote:

> On Aug 15, 2007, at 09:39:44, Rene Herman wrote:
>> On 08/15/2007 03:33 PM, Satyam Sharma wrote:
>>
>> [ git info --maintainer ]
>>
>>> I'd really _love_ a tool that does all that what you've proposed 
>>> above!  But why does it have to be "git-info" or anything in the 
>>> git(7) suite for that matter? This sounds like a job for a different 
>>> specialised tool,  long with ".metatags" kind of files dispersed in 
>>> the source tree.
>>
>> To automatically move (and delete) the meta-data alongside the files 
>> themselves is a reason.
>>
>> More generally -- shouldn't it? This is about source management (well, 
>> maybe more about project management, but...) and the source code 
>> management tool looks to be the right place for that. The different 
>> parts of git are somewhat/fairly stand-alone as is, no?
> 
> 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...

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/