Am Samstag 03 Juli 2010, 14:54:55 schrieb Johan Hedberg: > Your tree seems to contain lots of good stuff. Any reason why you > haven't requested an upstream merge earlier? The changes span from early > march to the end of june so it seems this would have been possible a > long time ago. Now the change set is quite huge and will take a long > time to properly review. After a quick skim though I didn't find > anything really critical, but there seem to be plenty of white space > issues that'd be nice to get fixed. Also, please keep your commit > message width at max 72 characters so they're readable with git log on > 80 character terminals. > > The whitespace issues I noticed fall mainly into the following > categories: > - over 80-character line (ok if the existing code had that issue too) > - white space at the end of line before line terminator > - some empty lines not being really empty but containing tabs or spaces
Those are OK to fix. > - mixed tabs and spaces for indentation > - more than one consecutive empty line > - space between function name and opening ( These are pure coding rules that are defined by personal preference. There are no clearly defined coding rules for the openobex code base. Can we stick to whatever git complains about? To enforce coding rules later, we may add vim and/or emacs instruction footers/headers. Note: all versions of git that I used so far complain about whitespace issues for files that have \r\n line endings :-( We have such files in OpenOBEX. > If you're using vim or have it available maybe you could try that too? I'm an Emacs user ;) and only use vi on system where nothing else is available. > I understand that it can be tricky to start fixing old commits when you > have so many new ones that might depend on their content (causing > potential conflicts if you go changing stuff), so if it gets too > complicated I suppose having coding-style fixup commits on top of the > existing changes is the only option (we had this situation some time > with obexd when INdT's own trees changes grew too big). However, if at > all possible, try to fix the existing commits in place. > > Also, it'd be good to avoid commits that fix regressions in other > non-upstream commits. The last one, "Fix libusb-0.x transport, broke > with b5b64ffc", is one of those. In that case I think it'd be better to > just redo commit b5b64ffc not to introduce the regression. No problem, I will make a new set, clearly separating some change sets. HS ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
