kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Junio C Hamano	cd673c1f17	has_sha1_pack(): refactor "pretend these packs do not exist" interface 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>	16 years ago
Stephan Beyer	1b1dd23f2d	Make usage strings dash-less 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>	17 years ago
Linus Torvalds	54352bb274	Remove now unnecessary 'sync()' calls Since the pack-files are now always created stably on disk, there is no need to sync() before pruning lose objects or old stale pack-files. [jc: with Nico's clean-up] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Nicolas Pitre	93ff3f6a53	return the prune-packed progress display to the inner loop This reverts commit `0e54913796` so to return to the same state as commit `b5d72f0a4c`. On Wed, 31 Oct 2007, Shawn O. Pearce wrote: > During my testing with a 40,000 loose object case (yea, I fully > unpacked a git.git clone I had laying around) my system stalled > hard in the first object directory. A lot longer than 1 second. > So I got no progress meter for a long time, and then a progress > meter appeared on the second directory. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Nicolas Pitre	4d4fcc5451	relax usage of the progress API Since it is now OK to pass a null pointer to display_progress() and stop_progress() resulting in a no-op, then we can simplify the code and remove a bunch of lines by not making those calls conditional all the time. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Nicolas Pitre	dc6a0757c4	make struct progress an opaque type This allows for better management of progress "object" existence, as well as making the progress display implementation more independent from its callers. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Nicolas Pitre	0e54913796	prune-packed: don't call display_progress() for every file The progress count is per fanout directory, so it is useless to call it for every file as the count doesn't change that often. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Shawn O. Pearce	b5d72f0a4c	Teach prune-packed to use the standard progress meter Rather than reimplementing the progress meter logic and always showing 100 lines of output while pruning already packed objects we now use a delayed progress meter and only show it if there are enough objects to make us take a little while. Most users won't see the message anymore as it usually doesn't take very long to delete the already packed loose objects. This neatens the output of a git-gc or git-repack execution, which is especially important for a `git gc --auto` triggered from within another command. We perform the display_progress() call from within the very innermost loop in case we spend more than 1 second within any single object directory. This ensures that a progress_update event from the timer will still trigger in a timely fashion and allow the user to see the progress meter. While I'm in here I changed the message to be more descriptive of its actual task. "Removing unused objects" is a little scary for new users as they wonder where these unused objects came from and how they should avoid them. Truth is these objects aren't unused in the sense of what git-prune would call a dangling object, these are used but are just duplicates of things we have already stored in a packfile. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	17 years ago
Matthias Lederhofer	bd67f09f6d	prune-packed: add -q to usage Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	b60daf0515	Make git-prune-packed a bit more chatty. Steven Grimm noticed that git-repack's verbosity is inconsistent because pack-objects is chatty and prune-packed is not. This makes the latter a bit more chatty and gives -q option to squelch it. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Alexandre Julliard	2bb10fe51e	prune-packed: Fix uninitialized variable. The dryrun variable was made local instead of static by the previous commit, and local variables aren't initialized to zero. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
J. Bruce Fields	2eb53e65bd	Make prune also run prune-packed Both the git-prune manpage and everday.txt say that git-prune should also prune unpacked objects that are also found in packs, by running git prune-packed. Junio thought this was "a regression when prune was rewritten as a built-in." So modify prune to call prune-packed again. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>	18 years ago
Junio C Hamano	106d710bc1	pack-objects --unpacked=<existing pack> option. 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>	19 years ago
Matthias Kestenholz	25f38f064f	use declarations from builtin.h for builtin commands Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Matthias Kestenholz	53bb2c002a	Make git-prune-packed a builtin Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	53228a5fb8	Make the rest of commands work from a subdirectory. These commands are converted to run from a subdirectory. commit-tree convert-objects merge-base merge-index mktag pack-objects pack-redundant prune-packed read-tree tar-tree unpack-file unpack-objects update-server-info write-tree Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	41f222e87a	Be marginally more careful about removing objects The git philosophy when it comes to disk accesses is "Laugh in the face of danger". Notably, since we never modify an existing object, we don't really care that deeply about flushing things to disk, since even if the machine crashes in the middle of a git operation, you can never really have lost any old work. At most, you'd need to figure out the proper heads (which git-fsck-objects can do for you) and re-do the operation. However, there's two exceptions to this: pruning and repacking. Those operations will actually _delete_ old objects that they know about in other ways (ie that they just repacked, or that they have found in other places). However, since they actually modify old state, we should thus be a bit more careful about them. If the machine crashes and the duplicate new objects haven't been flushed to disk, you can actually be in trouble. This is trivially stupid about it by calling "sync" before removing the objects. Not very smart, but we're talking about special operations than are usually done once a week if that. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	9106c097ad	Create object subdirectories on demand (phase II) This removes the unoptimization. The previous round does not mind missing fan-out directories, but still makes sure they exist, lest older versions choke on a repository created/packed by it. This round does not play that nicely anymore -- empty fan-out directories are not created by init-db, and will stay removed by prune-packed. The prune command also removes empty fan-out directories. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	b8041fe4d8	Sparse-directory safety fix. This will be removed when merging the second phase of Linus' "Create object subdirectories on demand" change anyway, but the code to recreate the empty .git/objects/??/ directory was confused. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	230f13225d	Create object subdirectories on demand This makes it possible to have a "sparse" git object subdirectory structure, something that has become much more attractive now that people use pack-files all the time. As a result of pack-files, a git object directory doesn't necessarily have any individual objects lying around, and in that case it's just wasting space to keep the empty first-level object directories around: on many filesystems the 256 empty directories will be aboue 1MB of diskspace. Even more importantly, after you re-pack a project that _used_ to be unpacked, you could be left with huge directories that no longer contain anything, but that waste space and take time to look through. With this change, "git prune-packed" can just do an rmdir() on the directories, and they'll get removed if empty, and re-created on demand. This patch also tries to fix up "write_sha1_from_fd()" to use the new common infrastructure for creating the object files, closing a hole where we might otherwise leave half-written objects in the object database. [jc: I unoptimized the part that really removes the fan-out directories to ease transition. init-db still wastes 1MB of diskspace to hold 256 empty fan-outs, and prune-packed rmdir()'s the grown but empty directories, but runs mkdir() immediately after that -- reducing the saving from 150KB to 146KB. These parts will be re-introduced when everybody has the on-demand capability.] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	51890a64eb	Call prune-packed from "git prune" as well. Add -n (dryrun) flag to git-prune-packed, and call it from "git prune". Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	54c6870ebf	Typofix: usage strings fix. The *_usage strings should not start with "usage: ", since the usage() function gives its own. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Linus Torvalds	2396ec85bd	Add "git-prune-packed" that removes objects that exist in a pack. This, together with "git repack" can be used to clean up unpacked git archives.	20 years ago

15 Commits (eed1fcd76d8893ab687c700e1729faea025ba7a8)