> From: Dinh Nguyen [mailto:dinguyen@xxxxxxxxxx] > Sent: Monday, June 23, 2014 3:44 PM > > On Fri, 2014-06-20 at 23:10 +0000, Paul Zimmerman wrote: ... >> Also, please do not post a patch series titled "[PATCH]" if you know >> that it should not be applied as-is. At least put an "RFC" in there so >> people will know it shouldn't be applied. >> > > Yes, apologies. I didn't think this patch series needed an RFC as the > the idea of this patch has been floating around for a while. And because > this patch series is just a respin of earlier efforts. Each patch can be > applied cleanly, but will not compile for different Kconfig options, as > I'm finding out from kbuild test robot. I need to rework this series so > that each patch will compile and maintain bisectability. > >> Really, you should learn to use git properly, instead of doing a bunch of >> work without it, and then throwing everything in at the last minute so >> you can create a patch series. Git should be your friend, not your enemy ;) >> > > You'd think that if I knew to add "RESEND" to my patch, I'd know to add > "RFC". I've been using git for quite some time now, and this is the 2nd > time that called out my "git" skills. Not sure how this oversight and > haste in my part could have been solved by git? Nah, I wasn't talking about the missing "RFC", that's just an oversight. I meant that if you checked in your work to git after making each change and compile-testing it, you would pretty much have a bisectible patch series without much extra work. "I need to rename struct s3c_hsotg to struct dwc2_hsotg." edit... compile... "Great, it compiles." git commit... "I need to move the suspend/resume code to common platform code." edit... compile... "Great, it compiles." git commit... And so on. -- Paul ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
