summaryrefslogtreecommitdiff
path: root/mergetools/tortoisemerge
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2020-06-04 19:54:38 +0200
committerLibravatar Junio C Hamano <gitster@pobox.com>2020-06-04 10:58:24 -0700
commitb5a2068cb1f879b8bff2bfbf99304091d03ce3af (patch)
tree586a77664958614133d9c21460b1f518757db75e /mergetools/tortoisemerge
parentupload-pack: use upload_pack_data fields in receive_needs() (diff)
downloadtgif-b5a2068cb1f879b8bff2bfbf99304091d03ce3af.tar.xz
upload-pack: actually use some upload_pack_data bitfields
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's actually start using some bitfields of that struct. These bitfields were introduced in 3145ea957d ("upload-pack: introduce fetch server command", 2018-03-15), but were never used. We could instead have just removed the following bitfields from the struct: unsigned use_thin_pack : 1; unsigned use_ofs_delta : 1; unsigned no_progress : 1; unsigned use_include_tag : 1; but using them makes it possible to remove a number of static variables with the same name and purpose from 'upload-pack.c'. This is a behavior change, as we accidentally used to let values in those bitfields propagate from one v2 "fetch" command to another for ssh/git/file connections (but not for http). That's fixing a bug, but one nobody is likely to see, because it would imply the client sending different capabilities for each request. Helped-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'mergetools/tortoisemerge')
0 files changed, 0 insertions, 0 deletions