summaryrefslogtreecommitdiff
path: root/builtin/fast-import.c
AgeCommit message (Collapse)AuthorFilesLines
2020-11-02Merge branch 'jk/fast-import-marks-cleanup'Libravatar Junio C Hamano1-1/+0
Code clean-up. * jk/fast-import-marks-cleanup: fast-import: remove duplicated option-parsing line
2020-10-16fast-import: remove duplicated option-parsing lineLibravatar Jeff King1-1/+0
Commit 1bdca81641 (fast-import: add options for rewriting submodules, 2020-02-22) accidentally added two lines parsing the option "rewrite-submodules-from". This didn't do anything in practice, because they're in an if/else chain and so the second one can never trigger. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-15fast-import: fix over-allocation of marks storageLibravatar Jeff King1-14/+17
Fast-import stores its marks in a trie-like structure made of mark_set structs. Each struct has a fixed size (1024). If our id number is too large to fit in the struct, then we allocate a new struct which shifts the id number by 10 bits. Our original struct becomes a child node of this new layer, and the new struct becomes the top level of the trie. This scheme was broken by ddddf8d7e2 (fast-import: permit reading multiple marks files, 2020-02-22). Before then, we had a top-level "marks" pointer, and the push-down worked by assigning the new top-level struct to "marks". But after that commit, insert_mark() takes a pointer to the mark_set, rather than using the global "marks". It continued to assign to the global "marks" variable during the push down, which was wrong for two reasons: - we added a call in option_rewrite_submodules() which uses a separate mark set; pushing down on "marks" is outright wrong here. We'd corrupt the "marks" set, and we'd fail to correctly store any submodule mappings with an id over 1024. - the other callers passed "marks", but the push-down was still wrong. In read_mark_file(), we take the pointer to the mark_set as a parameter. So even though insert_mark() was updating the global "marks", the local pointer we had in read_mark_file() was not updated. As a result, we'd add a new level when needed, but then the next call to insert_mark() wouldn't see it! It would then allocate a new layer, which would also not be seen, and so on. Lookups for the lost layers obviously wouldn't work, but before we even hit any lookup stage, we'd generally run out of memory and die. Our tests didn't notice either of these cases because they didn't have enough marks to trigger the push-down behavior. The new tests in t9304 cover both cases (and fail without this patch). We can solve the problem by having insert_mark() take a pointer-to-pointer of the top-level of the set. Then our push down can assign to it in a way that the caller actually sees. Note the subtle reordering in option_rewrite_submodules(). Our call to read_mark_file() may modify our top-level set pointer, so we have to wait until after it returns to assign its value into the string_list. Reported-by: Sergey Brester <serg.brester@sebres.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-06fast-import: use write_pack_header()Libravatar René Scharfe1-7/+1
Call write_pack_header() to hash and write a pack header instead of open-coding this function. This gets rid of duplicate code and of the magic version number 2 -- which has been used here since c90be46abd (Changed fast-import's pack header creation to use pack.h, 2006-08-16) and in pack.h (again) since 29f049a0c2 (Revert "move pack creation to version 3", 2006-10-14). Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-03Merge branch 'jk/slimmed-down'Libravatar Junio C Hamano1-0/+3640
Trim an unused binary and turn a bunch of commands into built-in. * jk/slimmed-down: drop vcs-svn experiment make git-fast-import a builtin make git-bugreport a builtin make credential helpers builtins Makefile: drop builtins from MSVC pdb list
2020-08-13make git-fast-import a builtinLibravatar Jeff King1-0/+3648
There's no reason that git-fast-import benefits from being a separate binary. And as it links against libgit.a, it has a non-trivial disk footprint. Let's make it a builtin, which reduces the size of a stripped installation from 22MB to 21MB. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>