Thanks, applied. I did happen to notice:
On Sun, Sep 25, 2016 at 4:57 PM, Dave Chinner <[email protected]> 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
