summaryrefslogtreecommitdiff
path: root/builtin-count-objects.c
AgeCommit message (Collapse)Author
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLinus Torvalds
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>
2009-12-30Merge branch 'maint-1.6.1' into maintJunio C Hamano
* maint-1.6.1: textconv: stop leaking file descriptors commit: --cleanup is a message option git count-objects: handle packs bigger than 4G t7102: make the test fail if one of its check fails Conflicts: builtin-commit.c diff.c
2009-12-30git count-objects: handle packs bigger than 4GAndreas Schwab
Use off_t to count sizes of packs and objects to avoid overflow after 4Gb. Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-25parse-opts: prepare for OPT_FILENAMEStephen Boyd
To give OPT_FILENAME the prefix, we pass the prefix to parse_options() which passes the prefix to parse_options_start() which sets the prefix member of parse_opts_ctx accordingly. If there isn't a prefix in the calling context, passing NULL will suffice. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-03Merge branch 'jc/maint-1.6.0-keep-pack' into maint-1.6.1Junio C Hamano
* jc/maint-1.6.0-keep-pack: pack-objects: don't loosen objects available in alternate or kept packs t7700: demonstrate repack flaw which may loosen objects unnecessarily Remove --kept-pack-only option and associated infrastructure pack-objects: only repack or loosen objects residing in "local" packs git-repack.sh: don't use --kept-pack-only option to pack-objects t7700-repack: add two new tests demonstrating repacking flaws is_kept_pack(): final clean-up Simplify is_kept_pack() Consolidate ignore_packed logic more has_sha1_kept_pack(): take "struct rev_info" has_sha1_pack(): refactor "pretend these packs do not exist" interface git-repack: resist stray environment variable
2009-04-09Merge branch 'jc/maint-1.6.0-keep-pack' into maintJunio C Hamano
* jc/maint-1.6.0-keep-pack: pack-objects: don't loosen objects available in alternate or kept packs t7700: demonstrate repack flaw which may loosen objects unnecessarily Remove --kept-pack-only option and associated infrastructure pack-objects: only repack or loosen objects residing in "local" packs git-repack.sh: don't use --kept-pack-only option to pack-objects t7700-repack: add two new tests demonstrating repacking flaws is_kept_pack(): final clean-up Simplify is_kept_pack() Consolidate ignore_packed logic more has_sha1_kept_pack(): take "struct rev_info" has_sha1_pack(): refactor "pretend these packs do not exist" interface git-repack: resist stray environment variable Conflicts: t/t7700-repack.sh
2009-02-28has_sha1_pack(): refactor "pretend these packs do not exist" interfaceJunio C Hamano
Most of the callers of this function except only one pass NULL to its last parameter, ignore_packed. Introduce has_sha1_kept_pack() function that has the function signature and the semantics of this function, and convert the sole caller that does not pass NULL to call this new function. All other callers and has_sha1_pack() lose the ignore_packed parameter. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-11add is_dot_or_dotdot inline functionAlexander Potashev
A new inline function is_dot_or_dotdot is used to check if the directory name is either "." or "..". It returns a non-zero value if the given string is "." or "..". It's applicable to a lot of Git source code. Signed-off-by: Alexander Potashev <aspotashev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-08Correct output of git-count-objects.Mikael Magnusson
The non-verbose output was not changed in fdb2a2a (compat: introduce on_disk_bytes(), 2008-08-18) which caused git-count-objects to claim 512 times too much space used for loose objects. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-21Merge branch 'mg/count-objects'Junio C Hamano
* mg/count-objects: count-objects: Add total pack size to verbose output
2008-08-19compat: introduce on_disk_bytes()Junio C Hamano
Some platforms do not have st_blocks member in "struct stat"; mingw already emulates it by rounding it up to closest 512-byte blocks (even though it could overcount when a file has holes). The reason to use the member is only to figure out how many kilobytes the files occupy on-disk, so give a helper function in git-compat-util.h to compute this value. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
2008-08-17count-objects: Add total pack size to verbose outputMarcus Griep
Adds the total pack size (including indexes) the verbose count-objects output, floored to the nearest kilobyte. Updates documentation to match this addition. Signed-off-by: Marcus Griep <marcus@griep.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13Make usage strings dash-lessStephan Beyer
When you misuse a git command, you are shown the usage string. But this is currently shown in the dashed form. So if you just copy what you see, it will not work, when the dashed form is no longer supported. This patch makes git commands show the dash-less version. For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh generates a dash-less usage string now. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-30Make builtin-count-objects.c use parse_options.Pierre Habouzit
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-30Simplify index access condition in count-objects, pack-redundantShawn O. Pearce
My earlier lazy index opening patch changed this condition to check index_data and call open_pack_index if it was NULL. In truth we only care about num_objects. Since open_pack_index does no harm if the index is already open, and all indexes are likely to be closed in this application, the "performance optimization" of inlining the index_data check here was wrong. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-27Lazily open pack index files on demandShawn O. Pearce
In some repository configurations the user may have many packfiles, but all of the recent commits/trees/tags/blobs are likely to be in the most recent packfile (the one with the newest mtime). It is therefore common to be able to complete an entire operation by accessing only one packfile, even if there are 25 packfiles available to the repository. Rather than opening and mmaping the corresponding .idx file for every pack found, we now only open and map the .idx when we suspect there might be an object of interest in there. Of course we cannot known in advance which packfile contains an object, so we still need to scan the entire packed_git list to locate anything. But odds are users want to access objects in the most recently created packfiles first, and that may be all they ever need for the current operation. Junio observed in b867092f that placing recent packfiles before older ones can slightly improve access times for recent objects, without degrading it for historical object access. This change improves upon Junio's observations by trying even harder to avoid the .idx files that we won't need. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-10get rid of num_packed_objects()Nicolas Pitre
The coming index format change doesn't allow for the number of objects to be determined from the size of the index file directly. Instead, Let's initialize a field in the packed_git structure with the object count when the index is validated since the count is always known at that point. While at it let's reorder some struct packed_git fields to avoid padding due to needed 64-bit alignment for some of them. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07Cast 64 bit off_t to 32 bit size_tShawn O. Pearce
Some systems have sizeof(off_t) == 8 while sizeof(size_t) == 4. This implies that we are able to access and work on files whose maximum length is around 2^63-1 bytes, but we can only malloc or mmap somewhat less than 2^32-1 bytes of memory. On such a system an implicit conversion of off_t to size_t can cause the size_t to wrap, resulting in unexpected and exciting behavior. Right now we are working around all gcc warnings generated by the -Wshorten-64-to-32 option by passing the off_t through xsize_t(). In the future we should make xsize_t on such problematic platforms detect the wrapping and die if such a file is accessed. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-27count-objects -v: show number of packs as well.Junio C Hamano
Recent "git push" keeps transferred objects packed much more aggressively than before. Monitoring output from git-count-objects -v for number of loose objects is not enough to decide when to repack -- having too many small packs is also a good cue for repacking. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-07pack-objects --unpacked=<existing pack> option.Junio C Hamano
Incremental repack without -a essentially boils down to: rev-list --objects --unpacked --all | pack-objects $new_pack which picks up all loose objects that are still live and creates a new pack. This implements --unpacked=<existing pack> option to tell the revision walking machinery to pretend as if objects in such a pack are unpacked for the purpose of object listing. With this, we could say: rev-list --objects --unpacked=$active_pack --all | pack-objects $new_pack instead, to mean "all live loose objects but pretend as if objects that are in this pack are also unpacked". The newly created pack would be perfect for updating $active_pack by replacing it. Since pack-objects now knows how to do the rev-list's work itself internally, you can also write the above example by: pack-objects --unpacked=$active_pack --all $new_pack </dev/null Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-04builtins: Makefile clean-upJunio C Hamano
This cleans up the build procedure for built-in commands by: - generating mostly redundant definition of BUILT_INS from BUILTIN_OBJS in the Makefile, - renaming a few files to make the above possible, and - sorting the built-in command table in git.c. It might be a good idea to binary search (or perfect hash) the built-in command table, but that can be done later when somebody feels like. Signed-off-by: Junio C Hamano <junkio@cox.net>