Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > As a maintainer, I am less concerned about the "result today" than I am > about keeping things easy and effortless to maintain. One of your patches > accomplishes that. The other one made it into `next`: > https://github.com/git/git/commit/91a67b86f77 I do not think reverting it and requeuing https://lore.kernel.org/git/20201107221916.1428757-1-dgurney99@xxxxxxxxx/ would help future folks why we ignore _MSC_VER as any sign usable to detect endianness, so I'd prefer to see a patch *on top* of 1af265f0 (compat/bswap.h: simplify MSVC endianness detection, 2020-11-08), which is 91a67b86f77^2, that explains why we prefer to list archs explicitly in its log message, which would be the primary value of that commit. Something along this line, perhaps? -- >8 -- Subject: compat/bswap.h: do not assume MSVC is little-endian only Earlier, with 1af265f0 (compat/bswap.h: simplify MSVC endianness detection, 2020-11-08), we tried to simplify endianness detection used in compat/bswap.h by assuming that any version Git compiled by MSVC (detected by _MSC_VER preprocessor macro) is meant to run on little endian boxes, as the versions of old MSVC that support m68k and MIPS do not support some C99 features used in the codebase anyway. While it might hold true that modern versions of Windows are all little-endian, MSVC is and/or can be ported to build for big-endian boxes, so tying _MSC_VER with endianness is a bit too restrictive. Let's go back to the old way to use _MSC_VER to learn what preprocessor macros compiler uses to tell us which arch we are building for, and list these arches that are little-endian explicitly. ... signed-off-by from you and helped-by from others ... Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> --- diffstat patch
