[PATCH] mtd: nand: use a local variable to simplify the nand_scan_tail

[Brian Norris]

On Mon, Oct 21, 2013 at 10:48:03AM -0700, Brian Norris wrote:
> On Sun, Oct 20, 2013 at 3:54 AM, Ezequiel Garcia
> <ezequiel.garcia at free-electrons.com> wrote:
> > On Sun, Oct 20, 2013 at 07:01:11AM +0000, Gupta, Pekon wrote:
> >> > From: Ezequiel Garcia [mailto:ezequiel.garcia at free-electrons.com]
> >> > > On Fri, Oct 18, 2013 at 02:11:19PM +0000, Gupta, Pekon wrote:
> >> > > Personally I won't prefer such stand-alone cleanup  _unless_ there is
> >> > > major driver re-write of the code, because this breaks the traceability
> >> > > via 'git blame'. And even in that case, this change should be applied first,
> >> > > and the other functional updates later.
> >> > >
> >> >
> >> > Hm.. I'm not sure I agree here. I like this patch and I like the effect
> >> > it has on nand_scan_tail().
> >> >
> >> > On a personal note, I hardly ever use git blame at all (because it's dead
> >> > slow). Instead, I just run git log ${file} and get the latest changes on
> >> > that file.
> >> >
> >> Its rather difficult to use 'git log' especially when you are tracing or debugging
> >> a generic driver, and want to know why this piece of code was introduced,
> >> and the idea behind it. 'git log' won’t show line by line commit details.
> >
> > Quite the opposite 'git log --patch' shows the commit details.
> > Or maybe you need something that I'm not aware of?
> >
> > I really don't think we should dis-encourage cleanups -in what ever form
> > and time they might come- just to preserve the last 'major' author of a file.
> 
> I'm fairly neutral regarding the value of this particular patch (it
> doesn't add a lot of value to me) but I agree with Ezequiel's
> sentiment. Unless we have a stronger reason for avoiding this change,
> I will probably take it.

There are some thoughts from others in the development community on this
very topic. See:

  http://lwn.net/Articles/571980/

Particularly this portion:

  Linus added that the reformatting of files to fix coding-style issues
  before applying small changes is "really nasty," leading to "conflicts
  from hell." It would be better to separate things like white-space
  changes from real work by a full release - or to not do the trivial
  changes at all. Ben Herrenschmidt suggested that white-space changes
  could be done at the end of a series, making them easy to drop, but
  Linus said that doesn't help, that the conflicts still come about. The
  best way to do white-space changes if they must be done, he said, is
  to do them to otherwise quiescent code. 

So this actually contradicts Pekon's claim :)

Anyway, I took the patch. Let people yell at me if this really causes
big problems.

Brian