Rene Herman [off-list ref] writes:
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?
Please step back a bit and imagine a world in which there was no
git. IOW, you kernel folks switched to tarballs and patches 20
months ago. It is a far superiour solution compared to CVS and
SVN, so it ought to work, right ;-)?
Now, would you implement the "whom would I send my patches to"
with EAs?
I would hope not.
Git or no git, I think a file that can be viewed with less,
edited with regular editor and processed with sed/perl/grep
tools is the way to go. I do not think adding 600+ patches to
the single MAINTAINERS list is workable in the longer term, as
it would become the single file many subsystem people need to
update and is asking for merge conflicts, but I think a file
with known name (say, "CcMe.txt") sprinkled in relevant
subdirectories, perhaps with the same format originally
suggested for MAINTAINERS, would make a lot more sense.
That would give people who work with tarballs and patches, or a
subsystem managed with something other than git (one of the most
important one is quilt), the equal access to the necessary data.
Even with git, it is my understanding that kernel community
works largely on patches exchanged over e-mails, between people
who do use git and people who do not. You would want to have
something you can easily transfer over e-mail in the patch
form.
We _could_ invent a new "patches to properties" git diff output
format that "git apply" can understand to propagate that
information, but that approach is making it less interoperable
with others, and you need to demonstrate the benefit far
outweighs that. I do not see it for this particular
application.
There may be places for "properties" that would be useful to
git, but I do not think the "find whom to send patches to" is
one of them.
On 08/16/2007 09:00 PM, Junio C Hamano wrote:
Git or no git, I think a file that can be viewed with less,
edited with regular editor and processed with sed/perl/grep
tools is the way to go. I do not think adding 600+ patches to
the single MAINTAINERS list is workable in the longer term, as
it would become the single file many subsystem people need to
update and is asking for merge conflicts, but I think a file
with known name (say, "CcMe.txt") sprinkled in relevant
subdirectories, perhaps with the same format originally
suggested for MAINTAINERS, would make a lot more sense.
That would give people who work with tarballs and patches, or a
subsystem managed with something other than git (one of the most
important one is quilt), the equal access to the necessary data.
That is ofcourse an argument but I believe a bit of a non-argument at the
same time in practice.
There's really not much point in pretending that non-git users are still
first class citizens anyway; Linus' own suggestion of using git-blame would
tie things to git as well, as do for example frequent requests to bisect a
problem. I moreover feel there's absolutely nothing wrong with that, given
that there's nothing wrong with git.
It's the kernel's source code management tool, is included out of the box in
most distributions nowadays and is GPLd meaning that the tool (itself) won't
keep anyone from exporting data from it and importing it into something else
if someone cares to. Also, I never managed to stay un-annoyed at source code
management tools long enough to understand why I wanted to use them but have
been using git for months now so as far as I am concerned, it appears to
even be a good tool.
But, well, anyways, I did look at a git repo a bit but will unfortunately
not be able to follow up the proposal with actual (good) code in a sensible
timeframe, let alone "quickly", which means I was hoping others would agree.
I believe these properties make for an elegant setup with many possible uses
including the maintainers information, but if you disagree I guess I'm going
to shelve it...
Even with git, it is my understanding that kernel community
works largely on patches exchanged over e-mails, between people
who do use git and people who do not. You would want to have
something you can easily transfer over e-mail in the patch
form.
We _could_ invent a new "patches to properties" git diff output
format that "git apply" can understand to propagate that
information
Yes, not unlike the current git move "meta-diffs" ...
but that approach is making it less interoperable with others, and you
need to demonstrate the benefit far outweighs that. I do not see it for
this particular application.
There may be places for "properties" that would be useful to git, but I
do not think the "find whom to send patches to" is one of them.
The important reason for wiring this into git directly would be keeping the
meta-data in sync with the data it refers to in an automated fashion. With
manual intervention, there's much more opportunity for things to grow stale.
In practice, it may not be a huge problem. It certainly is with the current
MAINTAINERS file but if one does finer-grained data around the tree, that
will probably help.
It's also not a now or never thing fortunately. If git does ever grow these
properties, the issue can be revisited, perhaps at that time both with the
experience of what the finer-grained in-tree solution did not solve and even
fewer people around that care about not making git even more of an intrinsic
part of development.
Rene.