Messages in this thread | | | From | Linus Torvalds <> | Date | Sun, 25 Sep 2016 18:21:05 -0700 | Subject | Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error |
| |
Thanks, applied.
I did happen to notice:
On Sun, Sep 25, 2016 at 4:57 PM, Dave Chinner <david@fromorbit.com> wrote: > > ./include/linux/pagemap.h: In function ¿fault_in_multipages_readable¿: > ./include/linux/pagemap.h:602:16: error: variable ¿c¿ set but not used [-Werror=unused-but-set-variable]
You have some nasty unicode corruption. The email is marked as being
Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
but those are not the right unicode characters. I think gcc actually uses back-tick and tick (which is ugly as hell in many fonts since they aren't generally necessarily symmetric, but oh well). So some cut-and-paste path of yours corrupted the utf8.
Obviously not a big deal, but you might want to look at your character set setting in your mailer or other environment. Perhaps some odd non-utf8 editor environment or something?
I also noticed:
> This is a regression caused by commit e23d415 ("fix > fault_in_multipages_...() on architectures with no-op access_ok()").
I'd suggest doing
git config --global core.abbrev 12
because the default git commit shortening value of 7 is practically too short for the kernel these days. What can I say? I was naïve, and based my original abbreviation decision on the BitKeeper numbers, where we were just about to hit 64k commits. So seven hex digits seemed plenty. And now, ten years later, I just look stupid.
Anyway - while git will always pick a shortname that is unique (ie it will add characters until it is unique), it's unique only at that moment in time. And practically speaking seven hex digits can easily have collisions in the hear future (ie it already happens with many commits).
So telling git "give me a minimum of 12 hex digits in hash abbreviations" should be fairly safe for a while.
I guess I should ping Junio and see if we can just change the default, but for smaller projects the default abbreviation is likely still reasonable. So I've been just mentioning that simple "set core.abbrev to 12" to kernel people..
Linus
| |