summaryrefslogtreecommitdiff
path: root/builtin/fsck.c
AgeCommit message (Collapse)AuthorFilesLines
2012-03-07fsck: use streaming API for writing lost-found blobsLibravatar Nguyễn Thái Ngọc Duy1-6/+2
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-28fsck: --no-dangling omits "dangling object" informationLibravatar Junio C Hamano1-2/+5
The default output from "fsck" is often overwhelmed by informational message on dangling objects, especially if you do not repack often, and a real error can easily be buried. Add "--no-dangling" option to omit them, and update the user manual to demonstrate its use. Based on a patch by Clemens Buchacher, but reverted the part to change the default to --no-dangling, which is unsuitable for the first patch. The usual three-step procedure to break the backward compatibility over time needs to happen on top of this, if we were to go in that direction. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13Rename resolve_ref() to resolve_ref_unsafe()Libravatar Nguyễn Thái Ngọc Duy1-1/+1
resolve_ref() may return a pointer to a shared buffer and can be overwritten by the next resolve_ref() calls. Callers need to pay attention, not to keep the pointer when the next call happens. Rename with "_unsafe" suffix to warn developers (or reviewers) before introducing new call sites. This patch is generated using the following command git grep -l 'resolve_ref(' -- '*.[ch]'|xargs sed -i 's/resolve_ref(/resolve_ref_unsafe(/g' Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-06fsck: print progressLibravatar Nguyễn Thái Ngọc Duy1-2/+38
fsck is usually a long process and it would be nice if it prints progress from time to time. Progress meter is not printed when --verbose is given because --verbose prints a lot, there's no need for "alive" indicator. Progress meter may provide "% complete" information but it would be lost anyway in the flood of text. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-06fsck: avoid reading every object twiceLibravatar Nguyễn Thái Ngọc Duy1-17/+25
During verify_pack() all objects are read for SHA-1 check. Then fsck_sha1() is called on every object, which read the object again (fsck_sha1 -> parse_object -> read_sha1_file). Avoid reading an object twice, do fsck_sha1 while we have an object uncompressed data in verify_pack. On git.git, with this patch I got: $ /usr/bin/time ./git fsck >/dev/null 98.97user 0.90system 1:40.01elapsed 99%CPU (0avgtext+0avgdata 616624maxresident)k 0inputs+0outputs (0major+194186minor)pagefaults 0swaps Without it: $ /usr/bin/time ./git fsck >/dev/null 231.23user 2.35system 3:53.82elapsed 99%CPU (0avgtext+0avgdata 636688maxresident)k 0inputs+0outputs (0major+461629minor)pagefaults 0swaps Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-06fsck: return error code when verify_pack() goes wrongLibravatar Nguyễn Thái Ngọc Duy1-1/+3
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-11fsck: do not abort upon finding an empty blobLibravatar Junio C Hamano1-6/+3
Asking fwrite() to write one item of size bytes results in fwrite() reporting "I wrote zero item", when size is zero. Instead, we could ask it to write "size" items of 1 byte and expect it to report that "I wrote size items" when it succeeds, with any value of size, including zero. Noticed and reported by BJ Hargrave. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-22Remove unused variablesLibravatar Johannes Schindelin1-2/+1
Noticed by gcc 4.6.0. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-01-27fsck: do not give up too early in fsck_dir()Libravatar Junio C Hamano1-6/+12
When there is a random garbage file whose name happens to be 38-byte long in a .git/objects/??/ directory, the loop terminated prematurely without marking all the other files that it hasn't checked in the readdir() loop. Treat such a file just like any other garbage file, and do not break out of the readdir() loop. While at it, replace repeated sprintf() calls to a single one outside the loop. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-01-27fsck: drop unused parameter from traverse_one_object()Libravatar Junio C Hamano1-3/+10
Also add comments to seemingly unsafe pointer dereferences, that are all safe. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-15add description parameter to OPT__VERBOSELibravatar René Scharfe1-1/+1
Allows better help text to be defined than "be verbose". Also make use of the macro in places that already had a different description. No object code changes intended. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLibravatar Linus Torvalds1-0/+684
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>