[lkml]   [2007]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/
    Rene Herman <> 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

    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

    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.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-08-16 21:03    [W:0.024 / U:4.444 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site