summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-06-04upload-pack: move keepalive to upload_pack_dataLibravatar Christian Couder1-7/+14
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's move the 'keepalive' static variable into this struct. It is used by code common to protocol v0 and protocol v2. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-04upload-pack: pass upload_pack_data to upload_pack_config()Libravatar Christian Couder1-5/+5
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's pass that struct to upload_pack_config(), so that this function can use all the fields of the struct. This will be used in followup commits to move static variables that are set in upload_pack_config() into 'upload_pack_data'. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-04upload-pack: change multi_ack to an enumLibravatar Christian Couder1-6/+10
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's take this opportunity to change the 'multi_ack' variable, which is now part of 'upload_pack_data', to an enum. This will make it clear which values this variable can take. Helped-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-04upload-pack: move multi_ack to upload_pack_dataLibravatar Christian Couder1-10/+10
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's move the multi_ack static variable into this struct. It is only used by protocol v0 code since protocol v2 assumes certain baseline capabilities, but rolling it into upload_pack_data and just letting v2 code ignore it as it does now is more coherent and cleaner. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-04upload-pack: move filter_capability_requested to upload_pack_dataLibravatar Christian Couder1-3/+3
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's move the filter_capability_requested static variable into this struct. It is only used by protocol v0 code since protocol v2 assumes certain baseline capabilities, but rolling it into upload_pack_data and just letting v2 code ignore it as it does now is more coherent and cleaner. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-04upload-pack: move use_sideband to upload_pack_dataLibravatar Christian Couder1-15/+19
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's move the 'use_sideband' static variable into this struct. This variable is used by both v0 and v2 protocols. While at it, let's update the comment near the variable definition. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-04upload-pack: move static vars to upload_pack_dataLibravatar Christian Couder1-14/+14
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's move the 'no_done', 'daemon_mode' and 'timeout' variables into this struct. They are only used by protocol v0 code since protocol v2 assumes certain baseline capabilities, but rolling them into upload_pack_data and just letting v2 code ignore them as it does now is more coherent and cleaner. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-04upload-pack: annotate upload_pack_data fieldsLibravatar Christian Couder1-5/+10
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's annotate fields from this struct to let people know which ones are used only for protocol v0 and which ones only for protocol v2. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-04upload-pack: actually use some upload_pack_data bitfieldsLibravatar Jeff King1-15/+14
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>
2020-05-18upload-pack: use upload_pack_data fields in receive_needs()Libravatar Christian Couder1-15/+13
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's use fields from this struct in receive_needs(), instead of local variables with the same name and purpose. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-18upload-pack: pass upload_pack_data to create_pack_file()Libravatar Christian Couder1-15/+9
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's pass that struct to create_pack_file(), so that this function, and the function it calls, can use all the fields of the struct. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-18upload-pack: remove static variable 'stateless_rpc'Libravatar Christian Couder1-6/+7
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's remove the 'stateless_rpc' static variable, as we can now use the field of 'struct upload_pack_data' with the same name instead. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-18upload-pack: pass upload_pack_data to check_non_tip()Libravatar Christian Couder1-7/+6
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's pass that struct to check_non_tip(), so that this function and the functions it calls, can use all the fields of the struct in followup commits. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-18upload-pack: pass upload_pack_data to send_ref()Libravatar Christian Couder1-3/+4
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's pass that struct to send_ref(), so that this function, and the functions it calls, can use all the fields of the struct in followup commits. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-18upload-pack: move symref to upload_pack_dataLibravatar Christian Couder1-5/+7
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, we are passing around that struct to many functions, so let's also pass 'struct string_list symref' around at the same time by moving it from a local variable in upload_pack() into a field of 'struct upload_pack_data'. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-18upload-pack: use upload_pack_data writer in receive_needs()Libravatar Christian Couder1-5/+3
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's use the 'struct packet_writer writer' field from 'struct upload_pack_data' in receive_needs(), instead of a local 'struct packet_writer writer' variable. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-18upload-pack: pass upload_pack_data to receive_needs()Libravatar Christian Couder1-9/+8
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's pass 'struct upload_pack_data' to receive_needs(), so that this function and the functions it calls can use all the fields of that struct in followup commits. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-18upload-pack: pass upload_pack_data to get_common_commits()Libravatar Christian Couder1-13/+13
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's pass 'struct upload_pack_data' to get_common_commits(), so that this function and the functions it calls can use all the fields of that struct in followup commits. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-18upload-pack: use 'struct upload_pack_data' in upload_pack()Libravatar Christian Couder1-15/+17
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's use 'struct upload_pack_data' in upload_pack(). This will make it possible in followup commits to remove a lot of static variables and local variables that have the same name and purpose as fields in 'struct upload_pack_data'. This will also make upload_pack() work in a more similar way as upload_pack_v2(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-18upload-pack: move 'struct upload_pack_data' aroundLibravatar Christian Couder1-56/+56
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's move 'struct upload_pack_data' and the related upload_pack_data_init() and upload_pack_data_clear() functions towards the beginning of the file, so that this struct and its related functions can then be used by upload_pack() in a followup commit. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-18upload-pack: move {want,have}_obj to upload_pack_dataLibravatar Christian Couder1-23/+25
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's move the want_obj and have_obj object arrays into 'struct upload_pack_data'. These object arrays are used by both upload_pack() and upload_pack_v2(), for example when these functions call create_pack_file(). We are going to use 'struct upload_pack_data' in upload_pack() in a followup commit. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-18upload-pack: remove unused 'wants' from upload_pack_dataLibravatar Christian Couder1-4/+0
As we cleanup 'upload-pack.c' by using 'struct upload_pack_data' more thoroughly, let's remove 'struct object_array wants' from 'struct upload_pack_data', as it appears to be unused. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-14Git 2.27-rc0Libravatar Junio C Hamano2-1/+28
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-14Merge branch 'es/trace-log-progress'Libravatar Junio C Hamano2-0/+43
Teach codepaths that show progress meter to also use the start_progress() and the stop_progress() calls as a "region" to be traced. * es/trace-log-progress: trace2: log progress time and throughput
2020-05-14Merge branch 'jt/t5500-unflake'Libravatar Junio C Hamano1-6/+6
Test fix for a topic already in 'master' and meant for 'maint'. * jt/t5500-unflake: t5500: count objects through stderr, not trace
2020-05-14Merge branch 'sn/midx-repack-with-config'Libravatar Junio C Hamano3-5/+67
"git multi-pack-index repack" has been taught to honor some repack.* configuration variables. * sn/midx-repack-with-config: multi-pack-index: respect repack.packKeptObjects=false midx: teach "git multi-pack-index repack" honor "git repack" configurations
2020-05-14Merge branch 'ds/bloom-cleanup'Libravatar Junio C Hamano6-28/+49
Code cleanup and typofixes * ds/bloom-cleanup: completion: offer '--(no-)patch' among 'git log' options bloom: use num_changes not nr for limit detection bloom: de-duplicate directory entries Documentation: changed-path Bloom filters use byte words bloom: parse commit before computing filters test-bloom: fix usage typo bloom: fix whitespace around tab length
2020-05-14Merge branch 'rs/fsck-duplicate-names-in-trees'Libravatar Junio C Hamano2-2/+86
"git fsck" ensures that the paths recorded in tree objects are sorted and without duplicates, but it failed to notice a case where a blob is followed by entries that sort before a tree with the same name. This has been corrected. * rs/fsck-duplicate-names-in-trees: fsck: report non-consecutive duplicate names in trees
2020-05-14Merge branch 'ao/p4-d-f-conflict-recover'Libravatar Junio C Hamano2-2/+111
"git p4" learned to recover from a (broken) state where a directory and a file are recorded at the same path in the Perforce repository the same way as their clients do. * ao/p4-d-f-conflict-recover: git-p4: recover from inconsistent perforce history
2020-05-14Merge branch 'js/rebase-autosquash-double-fixup-fix'Libravatar Junio C Hamano2-2/+21
"rebase -i" segfaulted when rearranging a sequence that has a fix-up that applies another fix-up (which may or may not be a fix-up of yet another step). * js/rebase-autosquash-double-fixup-fix: rebase --autosquash: fix a potential segfault
2020-05-14Merge branch 'jc/codingstyle-compare-with-null'Libravatar Junio C Hamano1-0/+12
Doc update. * jc/codingstyle-compare-with-null: CodingGuidelines: do not ==/!= compare with 0 or '\0' or NULL
2020-05-14Merge branch 'cw/bisect-replay-with-dos'Libravatar Junio C Hamano2-0/+9
"git bisect replay" had trouble with input files when they used CRLF line ending, which has been corrected. * cw/bisect-replay-with-dos: bisect: allow CRLF line endings in "git bisect replay" input
2020-05-14Merge branch 'es/bugreport-with-hooks'Libravatar Junio C Hamano3-0/+68
"git bugreport" learned to report enabled hooks in the repository. * es/bugreport-with-hooks: bugreport: collect list of populated hooks
2020-05-13The ninth batchLibravatar Junio C Hamano1-0/+24
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-13Merge branch 'cc/upload-pack-v2-fetch-fix'Libravatar Junio C Hamano2-16/+25
Serving a "git fetch" client over "git://" and "ssh://" protocols using the on-wire protocol version 2 was buggy on the server end when the client needs to make a follow-up request to e.g. auto-follow tags. * cc/upload-pack-v2-fetch-fix: upload-pack: clear filter_options for each v2 fetch command
2020-05-13Merge branch 'ds/sparse-updates-oob-access-fix'Libravatar Junio C Hamano1-5/+5
The code to skip unmerged paths in the index when sparse checkout is in use would have made out-of-bound access of the in-core index when the last path was unmerged, which has been corrected. * ds/sparse-updates-oob-access-fix: unpack-trees: avoid array out-of-bounds error
2020-05-13Merge branch 'ss/submodule-set-url-in-c'Libravatar Junio C Hamano2-21/+33
Rewriting various parts of "git submodule" in C continues. * ss/submodule-set-url-in-c: submodule: port subcommand 'set-url' from shell to C
2020-05-13Merge branch 'dd/bloom-sparse-fix'Libravatar Junio C Hamano5-6/+6
Code clean-up. * dd/bloom-sparse-fix: bloom: fix `make sparse` warning
2020-05-13Merge branch 'jk/ci-only-on-selected-branches'Libravatar Junio C Hamano2-0/+68
Instead of always building all branches at GitHub via Actions, users can specify which branches to build. * jk/ci-only-on-selected-branches: ci: allow per-branch config for GitHub Actions
2020-05-13Merge branch 'ss/faq-fetch-pull'Libravatar Junio C Hamano1-0/+8
Random bits of FAQ. * ss/faq-fetch-pull: gitfaq: fetching and pulling a repository
2020-05-13Merge branch 'ss/faq-ignore'Libravatar Junio C Hamano1-0/+10
Random bits of FAQ. * ss/faq-ignore: gitfaq: files in .gitignore are tracked
2020-05-13Merge branch 'jc/auto-gc-quiet'Libravatar Junio C Hamano7-16/+24
Teach "am", "commit", "merge" and "rebase", when they are run with the "--quiet" option, to pass "--quiet" down to "gc --auto". * jc/auto-gc-quiet: auto-gc: pass --quiet down from am, commit, merge and rebase auto-gc: extract a reusable helper from "git fetch"
2020-05-13Merge branch 'cb/credential-doc-fixes'Libravatar Junio C Hamano3-25/+43
Minor in-code comments and documentation updates around credential API. * cb/credential-doc-fixes: credential: document protocol updates credential: update gitcredentials documentation credential: correct order of parameters for credential_match credential: update description for credential_from_url_gently
2020-05-13Merge branch 'tb/bitmap-walk-with-tree-zero-filter'Libravatar Junio C Hamano4-16/+90
The object walk with object filter "--filter=tree:0" can now take advantage of the pack bitmap when available. * tb/bitmap-walk-with-tree-zero-filter: pack-bitmap: pass object filter to fill-in traversal pack-bitmap.c: support 'tree:0' filtering pack-bitmap.c: make object filtering functions generic list-objects-filter: treat NULL filter_options as "disabled"
2020-05-13Merge branch 'tb/shallow-cleanup'Libravatar Junio C Hamano16-75/+124
Code cleanup. * tb/shallow-cleanup: shallow: use struct 'shallow_lock' for additional safety shallow.h: document '{commit,rollback}_shallow_file' shallow: extract a header file for shallow-related functions commit: make 'commit_graft_pos' non-static
2020-05-12trace2: log progress time and throughputLibravatar Emily Shaffer2-0/+43
Rather than teaching only one operation, like 'git fetch', how to write down throughput to traces, we can learn about a wide range of user operations that may seem slow by adding tooling to the progress library itself. Operations which display progress are likely to be slow-running and the kind of thing we want to monitor for performance anyways. By showing object counts and data transfer size, we should be able to make some derived measurements to ensure operations are scaling the way we expect. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-11completion: offer '--(no-)patch' among 'git log' optionsLibravatar SZEDER Gábor1-0/+1
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-11bloom: use num_changes not nr for limit detectionLibravatar Derrick Stolee2-2/+2
As diff_tree_oid() computes a diff, it will terminate early if the total number of changed paths is strictly larger than max_changes. This includes the directories that changed, not just the file paths. However, only the file paths are reflected in the resulting diff queue's "nr" value. Use the "num_changes" from diffopt to check if the diff terminated early. This is incredibly important, as it can result in incorrect filters! For example, the first commit in the Linux kernel repo reports only 471 changes, but since these are nested inside several directories they expand to 513 "real" changes, and in fact the total list of changes is not reported. Thus, the computed filter for this commit is incorrect. Demonstrate the subtle difference by using one fewer file change in the 'get bloom filter for commit with 513 changes' test. Before, this edited 513 files inside "bigDir" which hit this inequality. However, dropping the file count by one demonstrates how the previous inequality was incorrect but the new one is correct. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-11bloom: de-duplicate directory entriesLibravatar Derrick Stolee2-11/+28
When computing a changed-path Bloom filter, we need to take the files that changed from the diff computation and extract the parent directories. That way, a directory pathspec such as "Documentation" could match commits that change "Documentation/git.txt". However, the current code does a poor job of this process. The paths are added to a hashmap, but we do not check if an entry already exists with that path. This can create many duplicate entries and cause the filter to have a much larger length than it should. This means that the filter is more sparse than intended, which helps the false positive rate, but wastes a lot of space. Properly use hashmap_get() before hashmap_add(). Also be sure to include a comparison function so these can be matched correctly. This has an effect on a test in t0095-bloom.sh. This makes sense, there are ten changes inside "smallDir" so the total number of paths in the filter should be 11. This would result in 11 * 10 bits required, and with 8 bits per byte, this results in 14 bytes. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-11Documentation: changed-path Bloom filters use byte wordsLibravatar Derrick Stolee1-4/+4
In Documentation/technical/commit-graph-format.txt, the definition of the BIDX chunk specifies the length is a number of 8-byte words. During development we discovered that using 8-byte words in the Murmur3 hash algorithm causes issues with big-endian versus little- endian machines. Thus, the hash algorithm was adapted to work on a byte-by-byte basis. However, this caused a change in the definition of a "word" in bloom.h. Now, a "word" is a single byte, which allows filters to be as small as two bytes. These length-two filters are demonstrated in t0095-bloom.sh, and a larger filter of length 25 is demonstrated as well. The original point of using 8-byte words was for alignment reasons. It also presented opportunities for extremely sparse Bloom filters when there were a small number of changes at a commit, creating a very low false-positive rate. However, modifying the format at this point is unlikely to be a valuable exercise. Also, this use of single-byte granularity does present opportunities to save space. It is unclear if 8-byte alignment of the filters would present any meaningful performance benefits. Modify the format document to reflect reality. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>