summaryrefslogtreecommitdiff
path: root/INSTALL
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2019-02-06 21:00:22 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-02-06 18:56:45 -0800
commite2c2a37545f604988424100ed6b1732eb5f36b55 (patch)
tree0fdf6475b5953ad7a64bf266dc669b678a5f8928 /INSTALL
parentadd: use separate ADD_CACHE_RENORMALIZE flag (diff)
downloadtgif-e2c2a37545f604988424100ed6b1732eb5f36b55.tar.xz
add_to_index(): convert forgotten HASH_RENORMALIZE check
Commit 9e5da3d055 (add: use separate ADD_CACHE_RENORMALIZE flag, 2019-01-17) switched out using HASH_RENORMALIZE in our flags field for a new ADD_CACHE_RENORMALIZE flag. However, it forgot to convert one of the checks for HASH_RENORMALIZE into the new flag, which totally broke "git add --renormalize". To make matters even more confusing, the resulting code would racily pass the tests! The forgotten check was responsible for defeating the up-to-date check of the index entry. That meant that "git add --renormalize" would refuse to renormalize things that appeared stat-clean. But most of the time the test commands run fast enough that the file mtime is the same as the index mtime. And thus we err on the conservative side and re-hash the file, which is what "--renormalize" would have wanted. But if you're unlucky and cross that one-second boundary between writing the file and writing the index (which is more likely to happen on a slow or heavily-loaded system), then the file appears stat-clean. And "--renormalize" would effectively do nothing. The fix is straightforward: convert this check to use the right flag. Noticed-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'INSTALL')
0 files changed, 0 insertions, 0 deletions