aboutsummaryrefslogtreecommitdiff
path: root/Documentation/git-gc.txt
Commit message (Collapse)AuthorAge
* gc --aggressive: make --depth configurableNguyễn Thái Ngọc Duy2014-03-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When 1c192f3 (gc --aggressive: make it really aggressive - 2007-12-06) made --depth=250 the default value, it didn't really explain the reason behind, especially the pros and cons of --depth=250. An old mail from Linus below explains it at length. Long story short, --depth=250 is a disk saver and a performance killer. Not everybody agrees on that aggressiveness. Let the user configure it. From: Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [PATCH] gc --aggressive: make it really aggressive Date: Thu, 6 Dec 2007 08:19:24 -0800 (PST) Message-ID: <alpine.LFD.0.9999.0712060803430.13796@woody.linux-foundation.org> Gmane-URL: http://article.gmane.org/gmane.comp.gcc.devel/94637 On Thu, 6 Dec 2007, Harvey Harrison wrote: > > 7:41:25elapsed 86%CPU Heh. And this is why you want to do it exactly *once*, and then just export the end result for others ;) > -r--r--r-- 1 hharrison hharrison 324094684 2007-12-06 07:26 pack-1d46...pack But yeah, especially if you allow longer delta chains, the end result can be much smaller (and what makes the one-time repack more expensive is the window size, not the delta chain - you could make the delta chains longer with no cost overhead at packing time) HOWEVER. The longer delta chains do make it potentially much more expensive to then use old history. So there's a trade-off. And quite frankly, a delta depth of 250 is likely going to cause overflows in the delta cache (which is only 256 entries in size *and* it's a hash, so it's going to start having hash conflicts long before hitting the 250 depth limit). So when I said "--depth=250 --window=250", I chose those numbers more as an example of extremely aggressive packing, and I'm not at all sure that the end result is necessarily wonderfully usable. It's going to save disk space (and network bandwidth - the delta's will be re-used for the network protocol too!), but there are definitely downsides too, and using long delta chains may simply not be worth it in practice. (And some of it might just want to have git tuning, ie if people think that long deltas are worth it, we could easily just expand on the delta hash, at the cost of some more memory used!) That said, the good news is that working with *new* history will not be affected negatively, and if you want to be _really_ sneaky, there are ways to say "create a pack that contains the history up to a version one year ago, and be very aggressive about those old versions that we still want to have around, but do a separate pack for newer stuff using less aggressive parameters" So this is something that can be tweaked, although we don't really have any really nice interfaces for stuff like that (ie the git delta cache size is hardcoded in the sources and cannot be set in the config file, and the "pack old history more aggressively" involves some manual scripting and knowing how "git pack-objects" works rather than any nice simple command line switch). So the thing to take away from this is: - git is certainly flexible as hell - .. but to get the full power you may need to tweak things - .. happily you really only need to have one person to do the tweaking, and the tweaked end results will be available to others that do not need to know/care. And whether the difference between 320MB and 500MB is worth any really involved tweaking (considering the potential downsides), I really don't know. Only testing will tell. Linus Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'nd/gc-lock-against-each-other'Junio C Hamano2013-09-04
|\ | | | | | | | | * nd/gc-lock-against-each-other: gc: reject if another gc is running, unless --force is given
| * gc: reject if another gc is running, unless --force is givenNguyễn Thái Ngọc Duy2013-08-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This may happen when `git gc --auto` is run automatically, then the user, to avoid wait time, switches to a new terminal, keeps working and `git gc --auto` is started again because the first gc instance has not clean up the repository. This patch tries to avoid multiple gc running, especially in --auto mode. In the worst case, gc may be delayed 12 hours if a daemon reuses the pid stored in gc.pid. kill(pid, 0) support is added to MinGW port so it should work on Windows too. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-gc.txt, git-reflog.txt: document new expiry optionsMichael Haggerty2013-04-18
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | Document the new values that can be used for expiry values where their use makes sense: * git reflog expire --expire=[all|never] * git reflog expire --expire-unreachable=[all|never] * git gc --prune=all Other combinations aren't useful and therefore no documentation is added (even though they are allowed): * git gc --prune=never is redundant with "git gc --no-prune" * git prune --expire=all is equivalent to providing no --expire option * git prune --expire=never is a NOP Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* docs: stop using asciidoc no-inline-literalJeff King2012-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation: use [verse] for SYNOPSIS sectionsMartin von Zweigbergk2011-07-06
| | | | | | | | | | | | | | | | | | | | | | The SYNOPSIS sections of most commands that span several lines already use [verse] to retain line breaks. Most commands that don't span several lines seem not to use [verse]. In the HTML output, [verse] does not only preserve line breaks, but also makes the section indented, which causes a slight inconsistency between commands that use [verse] and those that don't. Use [verse] in all SYNOPSIS sections for consistency. Also remove the blank lines from git-fetch.txt and git-rebase.txt to align with the other man pages. In the case of git-rebase.txt, which already uses [verse], the blank line makes the [verse] not apply to the last line, so removing the blank line also makes the formatting within the document more consistent. While at it, add single quotes to 'git cvsimport' for consistency with other commands. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* doc: drop author/documentation sections from most pagesJeff King2011-03-11
| | | | | | | | | | | | | | | | | | | | | | | | | | The point of these sections is generally to: 1. Give credit where it is due. 2. Give the reader an idea of where to ask questions or file bug reports. But they don't do a good job of either case. For (1), they are out of date and incomplete. A much more accurate answer can be gotten through shortlog or blame. For (2), the correct contact point is generally git@vger, and even if you wanted to cc the contact point, the out-of-date and incomplete fields mean you're likely sending to somebody useless. So let's drop the fields entirely from all manpages except git(1) itself. We already point people to the mailing list for bug reports there, and we can update the Authors section to give credit to the major contributors and point to shortlog and blame for more information. Each page has a "This is part of git" footer, so people can follow that to the main git manpage.
* Merge branch 'maint'Junio C Hamano2010-12-19
|\ | | | | | | | | | | | | | | | | * maint: gitweb: Include links to feeds in HTML header only for '200 OK' response fsck docs: remove outdated and useless diagnostic userdiff: fix typo in ruby and python word regexes trace.c: mark file-local function static Fix typo in git-gc document.
| * Fix typo in git-gc document.Jiang Xin2010-12-17
| | | | | | | | | | | | | | | | The variable gc.packrefs for git-gc can be set to true, false and "notbare", not "nobare". Signed-off-by: Jiang Xin <jiangxin@ossxp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Change remote tracking to remote-tracking in non-trivial placesMatthieu Moy2010-11-03
|/ | | | | | | | To complement the straightforward perl application in previous patch, this adds a few manual changes. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2010-07-05
|\ | | | | | | | | | | | | * maint: t0006: test timezone parsing rerere.txt: Document forget subcommand Documentation/git-gc.txt: add reference to githooks
| * Documentation/git-gc.txt: add reference to githooksChris Packham2010-07-02
| | | | | | | | | | | | | | | | This advertises the existence of the 'pre-auto-gc' hook and adds a cross reference to where the hook is documented. Signed-off-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jc/maint-no-reflog-expire-unreach-for-head'Junio C Hamano2010-05-21
|\ \ | |/ |/| | | | | | | | | | | | | | | * jc/maint-no-reflog-expire-unreach-for-head: reflog --expire-unreachable: special case entries in "HEAD" reflog more war on "sleep" in tests Document gc.<pattern>.reflogexpire variables Conflicts: Documentation/config.txt
| * Document gc.<pattern>.reflogexpire variablesJunio C Hamano2010-04-14
| | | | | | | | | | | | | | | | 3cb22b8 (Per-ref reflog expiry configuration, 2008-06-15) added support for setting the expiry parameters differently for different reflog, but it was never documented. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Documentation: spell 'git cmd' without dash throughoutThomas Rast2010-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.
* | Documentation: format full commands in typewriter fontThomas Rast2010-01-10
|/ | | | | | | | | | | | | | Use `code snippet` style instead of 'emphasis' for `git cmd ...` according to the following rules: * The SYNOPSIS sections are left untouched. * If the intent is that the user type the command exactly as given, it is `code`. If the user is only loosely referred to a command and/or option, it remains 'emphasised'. Signed-off-by: Thomas Rast <trast@student.ethz.ch>
* Documentation/git-gc.txt: change "references" to "reference"Matt Kraai2009-10-20
| | | | | Signed-off-by: Matt Kraai <kraai@ftbfs.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation/git-gc.txt: default --aggressive window is 250, not 10Brandon Casey2009-09-29
| | | | | | | | The default --aggressive window has been 250 since 1c192f34 "gc --aggressive: make it really aggressive", released in git v1.6.3. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Fix overridable written with an extra 'e'Nanako Shiraishi2009-08-27
| | | | | Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* gc: make --prune useful again by accepting an optional parameterJohannes Schindelin2009-02-14
| | | | | | | | | | | With this patch, "git gc --no-prune" will not prune any loose (and dangling) object, and "git gc --prune=5.minutes.ago" will prune all loose objects older than 5 minutes. This patch benefitted from suggestions by Thomas Rast and Jan Krï¿œger. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* manpages: italicize git command names (which were in teletype font)Jonathan Nieder2008-07-05
| | | | | | | | | | | | | | | | | | | | | | | The names of git commands are not meant to be entered at the commandline; they are just names. So we render them in italics, as is usual for command names in manpages. Using doit () { perl -e 'for (<>) { s/\`(git-[^\`.]*)\`/'\''\1'\''/g; print }' } for i in git*.txt config.txt diff*.txt blame*.txt fetch*.txt i18n.txt \ merge*.txt pretty*.txt pull*.txt rev*.txt urls*.txt do doit <"$i" >"$i+" && mv "$i+" "$i" done git diff . Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation formatting and cleanupJonathan Nieder2008-07-01
| | | | | | | | | | | | Following what appears to be the predominant style, format names of commands and commandlines both as `teletype text`. While we're at it, add articles ("a" and "the") in some places, italicize the name of the command in the manual page synopsis line, and add a comma or two where it seems appropriate. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation: be consistent about "git-" versus "git "Jonathan Nieder2008-07-01
| | | | | | | | | | | | | | | | | | | | Since the git-* commands are not installed in $(bindir), using "git-command <parameters>" in examples in the documentation is not a good idea. On the other hand, it is nice to be able to refer to each command using one hyphenated word. (There is no escaping it, anyway: man page names cannot have spaces in them.) This patch retains the dash in naming an operation, command, program, process, or action. Complete command lines that can be entered at a shell (i.e., without options omitted) are made to use the dashless form. The changes consist only of replacing some spaces with hyphens and vice versa. After a "s/ /-/g", the unpatched and patched versions are identical. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* documentation: move git(7) to git(1)Christian Couder2008-06-06
| | | | | | | | As the "git" man page describes the "git" command at the end-user level, it seems better to move it to man section 1. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Manual subsection to refer to other pages is SEE ALSOJunio C Hamano2008-05-28
| | | | | | Consistently say so in all caps as it is customary to do so. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* doc/git-gc: add a note about what is collectedJeff King2008-04-24
| | | | | | | | | | It seems to be a FAQ that people try running git-gc, and then get puzzled about why the size of their .git directory didn't change. This note mentions the reasons why things might unexpectedly get kept. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* make it easier for people who just want to get rid of 'git gc --auto'Nicolas Pitre2008-03-19
| | | | | | | | Give a direct hint to those who feel highly annoyed by the auto gc behavior. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* gc: call "prune --expire 2.weeks.ago" by defaultJohannes Schindelin2008-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only reason we did not call "prune" in git-gc was that it is an inherently dangerous operation: if there is a commit going on, you will prune loose objects that were just created, and are, in fact, needed by the commit object just about to be created. Since it is dangerous, we told users so. That led to many users not even daring to run it when it was actually safe. Besides, they are users, and should not have to remember such details as when to call git-gc with --prune, or to call git-prune directly. Of course, the consequence was that "git gc --auto" gets triggered much more often than we would like, since unreferenced loose objects (such as left-overs from a rebase or a reset --hard) were never pruned. Alas, git-prune recently learnt the option --expire <minimum-age>, which makes it a much safer operation. This allows us to call prune from git-gc, with a grace period of 2 weeks for the unreferenced loose objects (this value was determined in a discussion on the git list as a safe one). If you want to override this grace period, just set the config variable gc.pruneExpire to a different value; an example would be [gc] pruneExpire = 6.months.ago or even "never", if you feel really paranoid. Note that this new behaviour makes "--prune" be a no-op. While adding a test to t5304-prune.sh (since it really tests the implicit call to "prune"), also the original test for "prune --expire" was moved there from t1410-reflog.sh, where it did not belong. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* gc: Add --quiet optionFrank Lichtenheld2008-03-01
| | | | | | | Pass -q option to git-repack. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Change git-gc documentation to reflect gc.packrefs implementation.Florian La Roche2008-01-09
| | | | | | | | | | | | | 56752391a8c0c591853b276e4fa0b45c34ced181 (Make "git gc" pack all refs by default) changed the default of gc.packrefs to true, to pack all refs by default in any repository. IOW, the users need to disable it explicitly if they want to by setting the config variable, since 1.5.3. However, we forgot to update the documentation. This fixes it. Signed-off-by: Florian La Roche <laroche@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation: rename gitlink macro to linkgitDan McGee2008-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock Asciidoc configuration: @@ -149,7 +153,10 @@ # Inline macros. # Backslash prefix required for escape processing. # (?s) re flag for line spanning. -(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + +# Explicit so they can be nested. +(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + # Anchor: [[[id]]]. Bibliographic anchor. (?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3 # Anchor: [[id,xreflabel]] This default regex now matches explicit values, and unfortunately in this case gitlink was being matched by just 'link', causing the wrong inline macro template to be applied. By renaming the macro, we can avoid being matched by the wrong regex. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation/git-gc: improve description of --autoJeff King2007-10-18
| | | | | | | | | | | | This patch tries to make the description of --auto a little more clear for new users, especially those referred by the "git-gc --auto" notification message. It also cleans up some grammatical errors and typos in the original description, as well as rewording for clarity. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Documentation/git-gc: explain --auto in descriptionJeff King2007-10-18
| | | | | | | | | | Now that git-gc --auto tells the user to look at the man page, it makes sense to mention the auto behavior near the top (since this is likely to be most users' first exposure to git-gc). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gc --auto: run "repack -A -d -l" as necessary.Junio C Hamano2007-09-17
| | | | | | | | | | | This teaches "git-gc --auto" to consolidate many packs into one without losing unreachable objects in them by using "repack -A" when there are too many packfiles that are not marked with *.keep in the repository. gc.autopacklimit configuration can be used to set the maximum number of packs a repository is allowed to have before this mechanism kicks in. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-gc --auto: add documentation.Junio C Hamano2007-09-17
| | | | | | | This documents the auto-packing of loose objects performed by git-gc --auto. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix minor grammatical typos in the git-gc man pageTheodore Ts'o2007-05-31
| | | | | Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Add --aggressive option to 'git gc'Theodore Tso2007-05-10
| | | | | | | | | | | | This option causes 'git gc' to more aggressively optimize the repository at the cost of taking much more wall clock and CPU time. Today this option causes git-pack-objects to use --no-use-delta option, and it allows the --window parameter to be set via the gc.aggressiveWindow configuration parameter. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-gc: run pack-refs by default unless the repo is bareJohannes Schindelin2007-02-13
| | | | | | | | The config variable gc.packrefs is tristate now: "true", "false" and "notbare", where "notbare" is the default. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-gc: do not run git-prune by default.Junio C Hamano2007-01-21
| | | | | | | | git-prune is not safe when run uncontrolled in parallel while other git operations are creating new objects. To avoid mistakes, do not run git-prune by default from git-gc. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Documentation: a few spelling fixesRené Scharfe2007-01-17
| | | | | Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Create 'git gc' to perform common maintenance operations.Shawn O. Pearce2006-12-27
Junio asked for a 'git gc' utility which users can execute on a regular basis to perform basic repository actions such as: * pack-refs --prune * reflog expire * repack -a -d * prune * rerere gc So here is a command which does exactly that. The parameters fed to reflog's expire subcommand can be chosen by the user by setting configuration options in .git/config (or ~/.gitconfig), as users may want different expiration windows for each repository but shouldn't be bothered to remember what they are all of the time. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>