Hi Rene,


On Wed, 15 Aug 2007, Rene Herman wrote:

It mostly is just about that it seems. However, this would not also allow the
other information currently in the MAINTAINERS file to be queried in similar
ways.

Git could grow a generic file meta data implementation through the use of
tags, sort of like tags on multimedia files although while with multimedia
files the tags are in fact stored as a file header, here you'd keep them just
in git. Any project using git would be free to define its own set of info tags
and you'd supply them to git simply as a list of

<tag>=<value>

pairs:

$ git info --add drivers/ide/ide-cd.c <<EOF
CC="Alan Cox [off-list ref]", linux-ide@vger.kernel.org
EOF

Or as a more expansive example, with the tags set on a directory (and the
output shown this time):

$ git info drivers/infiniband/
CC="Roland Dreier [off-list ref]"
CC="Sean Hefty [off-list ref]"
CC="Hal Rosenstock [off-list ref]"
CC=openib-general@openib.org

Considering some people may want to differentiate between "those who want
to be Cc'ed for patches on subsystem X" and "those who are maintainer(s)
of subsystem X", I think another "P=" kind of tag might also be useful
here.

W=http://www.openib.org/
T=git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

$ git info --type="W" drivers/infiniband/
http://www.openib.org/

The project can link the actual tags such as CC, W and T to --options for the
"info" command in the git configuration file for the tree (and/or just define
a few upfront I guess) making it look nicer:

$ git info --cc drivers/infiniband/
"Roland Dreier [off-list ref]"
"Sean Hefty [off-list ref]"
"Hal Rosenstock [off-list ref]"
openib-general@openib.org

$ git info --website drivers/infiniband/
http://www.openib.org/

$ git info --tree drivers/infiniband/
git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

Extra: when you have such an implementation, you can use it for other purposes
as well such as the summary Documentation/ files want for the 00-INDEX files:

$ git info --summary Documentation/BUG-HUNTING
brute force method of doing binary search of patches to find bug.

And importantly -- when queuried for a file that itself doesn't have the
requested info tag:

$ git info --cc drivers/infiniband/core/addr.c

git looks for the tag on the drivers/infiniband/core/ directory next, and then
on drivers/infiniband/, where it finds it. linux-kernel@vger.kernel.org would
be the final fallback, being set on the project root.

I'd really like something like this. As long as projects are both free to use
and not use them and free to define their own set of tags I believe this would
work very nicely.

Once you have these tags, you can basically use them for anything.

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,
along with ".metatags" kind of files dispersed in the source tree.


Satyam