summaryrefslogtreecommitdiff
path: root/Documentation/RelNotes
diff options
context:
space:
mode:
authorLibravatar Elijah Newren <newren@gmail.com>2019-09-17 09:35:04 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-09-17 12:20:36 -0700
commit902b90cf42bc3c05f9fd124edac42ef1fc4ffafa (patch)
tree57e83312d6434e21d1fca863aac3b99e98ef052d /Documentation/RelNotes
parentclean: rewrap overly long line (diff)
downloadtgif-902b90cf42bc3c05f9fd124edac42ef1fc4ffafa.tar.xz
clean: fix theoretical path corruption
cmd_clean() had the following code structure: struct strbuf abs_path = STRBUF_INIT; for_each_string_list_item(item, &del_list) { strbuf_addstr(&abs_path, prefix); strbuf_addstr(&abs_path, item->string); PROCESS(&abs_path); strbuf_reset(&abs_path); } where I've elided a bunch of unnecessary details and PROCESS(&abs_path) represents a big chunk of code rather than an actual function call. One piece of PROCESS was: if (lstat(abs_path.buf, &st)) continue; which would cause the strbuf_reset() to be missed -- meaning that the next path to be handled would have two paths concatenated. This path used to use die_errno() instead of continue prior to commit 396049e5fb62 ("git-clean: refactor git-clean into two phases", 2013-06-25), but my understanding of how correct_untracked_entries() works is that it will prevent both dir/ and dir/file from being in the list to clean so this should be dead code and the die_errno() should be safe. But I hesitate to remove it since I am not certain. However, we can fix both this bug and possible similar future bugs by simply moving the strbuf_reset(&abs_path) to the beginning of the loop. It'll result in N calls to strbuf_reset() instead of N-1, but that's a small price to pay to avoid sneaky bugs like this. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/RelNotes')
0 files changed, 0 insertions, 0 deletions