On Mon, Feb 25, 2008 at 07:57:13PM +0100, Matthieu Moy wrote:
> Yes, but a sane default address to send to can be given by the
> repository you make your original clone from.
>
> The really nice thing with the way darcs does it is that it makes it
> extremely easy for an occasional contribution. If the maintainer
> configured his stuff correctly, it's really "darcs get; ... ; darcs
> record; darcs send". git-send-email is nice, but harder to use for a
> first-timer.
I agree that this is useful, especially for smaller projects where it
really _is_ just one address.
> > - this information could be shipped as part of the repo (i.e., under
> > version control like the rest of the project, as it changes with the
> > project)
>
> True, but for the case of multiple maintainers, that would break
> merging between maintainers on that particular part.
>
> You can have a maintainer A advertizing for A@xxxxxxxxxx, and a
> "sub-maintainer" B advertizing for B@xxxxxxxxxxx If A merges from B,
> he doesn't want his advertized adress to become the one of B.
I think there are advantages and drawbacks to both methods.
Version-controlled information is better for a project that has multiple
official maintainers, and those maintainers want to submit a patch
saying "and here's my contacat information." But it's worse for people
who are saying "here's somebody else's repo with my patches, but email
me about it".
Worse, you may want to do either in a particular repo, depending on what
your patches are. If I publish a repo with patches on top of git.git,
then you want to email me for patches specific to my repo, but probably
the regular git list and subsystem maintainers for patches that are
generally applicable.
So I'm not sure you will be able to write a tool that will always just
do the right thing.
> > - this information can potentially be inferred from git shortlog
> > and/or blame; this addresses the problem of data becoming stale
>
> Yes and no. git@xxxxxxxxxxxxxxx won't appear anywhere in these for
> example.
Yes, there would need to be some tool that combines:
- per-repo patch submitting policy (i.e., mail me because I am your
upstream)
- per-project patch submitting policy (i.e., mail git@vger for git
patches)
- per-patch policy (e.g., this patch touches foo.c: who is
interested in foo.c?)
-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
