linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Omar Sandoval <osandov@osandov.com>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <jbacik@fb.com>,
	linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] btrfs: fix sparse address space warnings
Date: Mon, 29 Sep 2014 23:49:54 +0200	[thread overview]
Message-ID: <20140929214954.GG11436@suse.cz> (raw)
In-Reply-To: <20140929194512.GA7038@mew.dhcp4.washington.edu>

On Mon, Sep 29, 2014 at 12:45:12PM -0700, Omar Sandoval wrote:
> > > @@ -639,8 +640,7 @@ static int send_header(struct send_ctx *sctx)
> > > -	return write_buf(sctx->send_filp, &hdr, sizeof(hdr),
> > > -					&sctx->send_off);
> > > +	return write_buf(sctx->send_filp, &hdr, sizeof(hdr), &sctx->send_off);
> > 
> > >  	ret = write_buf(sctx->send_filp, sctx->send_buf, sctx->send_size,
> > > -					&sctx->send_off);
> > > +			&sctx->send_off);
> > 
> > Please do not fold unrelated changes.
> 
> My metric for "related" here was that these were call sites of a function I
> directly modified.

The changes are only in the whitespace, that's not necessary. It's
usually ok to fix style issues in the code you modify directly.

> Is the preferred form to just split style fixes that we encounter into
> a separate patch in the series?

Well, I may only express my point of view. Yes, split the style-only
changes into another patch and don't send it :)

The problem with patches that do not effectively change anything is that
they pollute git history and just add extra step when one has to look
for a patch that broke something, or eg. change context of following
patches and make backporting a bit more tedious. Code cleanups are fine,
but there's usually a point of making the code more readable, compact,
etc.

The coding style should be perfect from the beginning. Nobody will
probably point out minor style violations during review, because it just
pointless for a patch that fixes a real bug.

  reply	other threads:[~2014-09-29 21:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-28  8:48 [PATCH 0/2] btrfs: fix several sparse warnings Omar Sandoval
2014-09-28  8:48 ` [PATCH 1/2] btrfs: fix sparse address space warnings Omar Sandoval
2014-09-28 22:26   ` Omar Sandoval
2014-09-30 19:27     ` Zach Brown
2014-09-30 20:32       ` Omar Sandoval
2014-09-29 16:07   ` David Sterba
2014-09-29 19:45     ` Omar Sandoval
2014-09-29 21:49       ` David Sterba [this message]
2014-09-28  8:48 ` [PATCH 2/2] btrfs: fix sparse lock context warnings Omar Sandoval
2014-09-29 16:10   ` David Sterba
2014-09-28  8:52 ` [PATCH 0/2] btrfs: fix several sparse warnings Omar Sandoval

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140929214954.GG11436@suse.cz \
    --to=dsterba@suse.cz \
    --cc=clm@fb.com \
    --cc=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=osandov@osandov.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).