Christian Couder <christian.couder@xxxxxxxxx> writes: > This patch series is the second part of an effort to move all static > variables in 'upload-pack.c' into 'struct upload_pack_data'. > > It is based on 'cc/upload-pack-data' which contains "part 1" of this > effort. (See also: https://lore.kernel.org/git/20200515100454.14486-1-chriscool@xxxxxxxxxxxxx/) > > A part 3 will follow with the rest of the patches needed to get rid of > the static variables left after this patch series. > > Thanks to Peff for his review of the first and second versions of this > part 2: > > V1: https://lore.kernel.org/git/20200527164742.23067-1-chriscool@xxxxxxxxxxxxx/ > V2: https://lore.kernel.org/git/20200602041657.7132-1-chriscool@xxxxxxxxxxxxx/ > > Thanks to Jonathan Tan for his review of V2 too. > > Compared to V2 the changes are the following: > > - patch 01/13 integrates Jonathan's commit message improvement > > - patch 07/13 integrates Jonathan's fixup patch which makes > multi_ack enum values all-caps and fixes a spacing issue (2 spaces > between "enum" and "{") Thanks, all. I notice that enumeration constants for "enum multi_ack" have been upcased; I do not think it matters too much either way. A situation that strongly favours upper case is when the enum is the result of converting from C preprocessor macros that were spelled with upper case, but this is not one of those. > There is a lot of noise in the range-diff with V2, because V3 contains > Peff's 'Acked-by:' and Junio's 'Signed-off-by', but here it is: Would it work as a "trick" to fetch what has been queued in 'pu' and compare against that lets you avoid such a "noise", I wonder? If it works well, it would have an added benefit of having the publically-known commit object names on the left hand side (e.g. instead of e5c31f30ec, you'd see d293806610 as the patch 1 from the second iteration) of the range-diff. > 1: e5c31f30ec ! 1: 12f8a9c953 upload-pack: actually use some upload_pack_data bitfields
