On 2012.7.24 2:51 PM, Junio C Hamano wrote:
> Michael G Schwern <schwern@xxxxxxxxx> writes:
>
>> A big one is "do not blast 10 emails to a mailing list" but I gather that's ok
>> here if a submission needs 10 commits to be well expressed and its done via
>> git-send-email? And then if patch #3 needs revision I'm to do it in a rebase
>> and resend the whole 10 commits? Am I to think of git-send-email less as a
>> means of sending patches to a mailing list and more as a git transport mechanism?
>
> Yes, yes and whatever (even though I think send-email is just a
> better MUA/MSA when you want to send patches and isn't restricted
> for a _git_ transport, I do not think it matters how you look at it).
#3 was not intended as a dig. If I can think about git-send-email like a
funny way to do a git-push then that fits better in my head. I worry about
sending too many emails to a list at once. I don't worry about sending too
many commits in one push.
>> I'm trying to bust it up into easier to digest pieces. I came into this cold
>> without much knowledge of the problem ("something to do with
>> canonicalization") and no knowledge of the code.
>
> Perhaps it is a good idea to lurk and see how others submit their
> topics first?
While I use git heavily I'm not invested in working on it. I work on a lot of
projects. I'd like to be able to do the work, submit it, work through review,
and get out without joining another mailing list and studying their culture.
Is there a document I could look at for submitting a large body of work, or
could I help improve SubmittingPatches to document the process better?
--
I do have a cause though. It's obscenity. I'm for it.
- Tom Lehrer
--
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