Re: [PATCH 2/5] staging: cxt1e1: remove dead code in musycc.c

From: DaeSeok Youn
Date: Fri May 09 2014 - 10:25:40 EST


2014-05-09 23:15 GMT+09:00, Dan Carpenter <dan.carpenter@xxxxxxxxxx>:
> On Fri, May 09, 2014 at 11:09:35PM +0900, DaeSeok Youn wrote:
>> 2014-05-09 19:51 GMT+09:00, Dan Carpenter <dan.carpenter@xxxxxxxxxx>:
>> > On Fri, May 09, 2014 at 07:06:06PM +0900, Daeseok Youn wrote:
>> >> Removes "#if 0" blocks.
>> >>
>> >> Signed-off-by: Daeseok Youn <daeseok.youn@xxxxxxxxx>
>> >> ---
>> >> Dan,
>> >> I decided to leave musycc_dump_rxbuffer_ring(ch, 0) which is
>> >> commented
>> >> out and make a block as "RLD_DEBUG". Because i think this block need
>> >> to
>> >> debug
>> >> with define "RLD_DEBUG". If I am wrong, let me know.
>> >>
>> >
>> > This change should maybe have been in a separate patch. It's a border
>> > line thing. But definitely, it should have been mentioned in the
>> > changelog.
>> >
>> > Btw, you can use `git citool` to add or remove lines from a
>> > commit. Highlight and right click on the lines you want to add or
>> > remove.
>> Thanks for the tip. I used "git add -p" after "git rebase" and "git
>> reset HEAD" for
>> spliting a patch.
>> But I have a question, Do I have to resend rest of patches after
>> spliting this patch?
>> In this case, 2/5 is splited to two, it doesn't need to rebase but
>> numbering of patches are changed.
>
> Probably it's simplest to just fixup the changelog and resend as-is.
> If you split a patch then normally it's easiest to just resend
> everything.
>
> If you have to resend just one patch and it doesn't affect the later
> patches then you can just resend that one so long as you get the
> In-Reply-To email header correct. If you don't know what an In-Reply-To
> header is, then resend everything.
>
Thanks for kind explanation.
I will just change the changelog and send this again.

Regards,
Daeseok Youn

> regards,
> dan carpenter
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/