'Twas brillig, and Kim Lester at 31/07/09 17:22 did gyre and gimble: > > On 01/08/2009, at 12:55 AM, Lennart Poettering wrote: > >>> >> >> Please, next time attach them uncompressed and inline, makes it easier >> to comment on. > > Ok - but historically newgroup readers have tend to flame people who add > 20K+ of patches inline on a discussion group.... > Times change. Yeah, I think git brought about that change - inline reviews of emails and the fact that "a patch is an email" kinda makes this the case. Generally you'll commit separate patches as separate posts to the list - git send-email makes this a breeze. For and example see Lennarts own post to the alsa list today: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-July/thread.html#19861 (neer the bottom : the subject start: [PATCH 1/4] ..... It makes it easy for inline review of changes/comments etc. (which I did to Lennart's commit over there as you'll see!) > Hmmm. I probably can but it's going to take me a number of hours to sort > out and I can't do it until later next the week. > If you _have_ to have it let me know and I'll try and get around to it. > I understand they are orthogonal edits but surely they are of relatively > little value individually? > I have always tended to commit a logically related and self consistent > set of changes - in this case "make OS X compile/run". > Is it a "git" mindset or a "PA" mindset to commit minimal deltas ? > I will stay minimal in future. I think it's more about the what the fixes do. In this case to "make OS X work, there are several small but ultimately unrelated (in the wider picture) changes. With git is quite easy to create these separate commits locally (on a branch), post separately for peer review and then make changes to indivudual commits+reapply other commits. Ultimately the git tree you start off with initially is unlikely to be the one used after review, but git makes this pretty easy (git checkout -b new try <last good commit ref> + git cherry-pick and such like are your friend here) >> Also, you'd do me a great favour if you could follow the rules pointed >> out here: >> >> http://pulseaudio.org/wiki/CodingStyle > > I say tom-ah-to .. you say tom-a-to. > I've read it now. > I happen to voilently disagree with point 3 :-) given space is not a > problem these days. I *like* my braces to line up vertically. Its far > more elegant IMHO than opening braces way off in never-never land on RHS > of screen. For the record, I agree with you. I also like balanced braces (e.g. if one side of an if/else has braces, both should have them), but that's another tangent. I code for several projects with various different styles. It's annoying switching around but you get used to it :) > Still at least you're very sensible with 4 space indents. I just don't > get these 3-space indent weirdos!!! :-) I prefer 2. /me ducks. :p Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
