Andy Parkins wrote:
Digressing a little: what is the polite form of patches for git? My strategy
with this set was to make each patch as small as possible to reach my end
point. If those patches were okayed on the list, I could then do a "make
more beautiful" patch, which is really nothing to do with the original
changes to functionality but would make the code prettier.
I believe the order of preferrence goes: tested, concise, short.
Linus has a nasty habit of ending his mails with "totally untested
ofcourse", which is not a good strategy to adopt if you want your
patches included.
Really I'm asking
what level of intrusiveness of patch is not considered rude? In making my
patches, should I ride rough-shod over current implementation and just do it
how I'd do it or should I try to fit in (as I did in this case)?
If you *need* to change something, change it. If you *want* to change
something just because it's not written the way you would write it, back
away. If you think some interface you're using needs clearing up
(codewise or with extra comments), send a separate patch for that so the
actual feature/bugfix you're sending in doesn't drown in cosmetic
changes to the interfaces the patch uses/touches.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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