lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140509141534.GK4963@mwanda>
Date:	Fri, 9 May 2014 17:15:34 +0300
From:	Dan Carpenter <dan.carpenter@...cle.com>
To:	DaeSeok Youn <daeseok.youn@...il.com>
Cc:	gregkh@...uxfoundation.org, himangi774@...il.com,
	sachin.kamat@...aro.org, fempsci@...il.com, nandu.hgowda@...il.com,
	devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] staging: cxt1e1: remove dead code in musycc.c

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@...cle.com>:
> > On Fri, May 09, 2014 at 07:06:06PM +0900, Daeseok Youn wrote:
> >> Removes "#if 0" blocks.
> >>
> >> Signed-off-by: Daeseok Youn <daeseok.youn@...il.com>
> >> ---
> >> 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.

regards,
dan carpenter

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ