path: root/Documentation/git-gc.txt
AgeCommit message (Collapse)Author
2019-09-05Recommend git-filter-repo instead of git-filter-branchElijah Newren
filter-branch suffers from a deluge of disguised dangers that disfigure history rewrites (i.e. deviate from the deliberate changes). Many of these problems are unobtrusive and can easily go undiscovered until the new repository is in use. This can result in problems ranging from an even messier history than what led folks to filter-branch in the first place, to data loss or corruption. These issues cannot be backward compatibly fixed, so add a warning to both filter-branch and its manpage recommending that another tool (such as filter-repo) be used instead. Also, update other manpages that referenced filter-branch. Several of these needed updates even if we could continue recommending filter-branch, either due to implying that something was unique to filter-branch when it applied more generally to all history rewriting tools (e.g. BFG, reposurgeon, fast-import, filter-repo), or because something about filter-branch was used as an example despite other more commonly known examples now existing. Reword these sections to fix these issues and to avoid recommending filter-branch. Finally, remove the section explaining BFG Repo Cleaner as an alternative to filter-branch. I feel somewhat bad about this, especially since I feel like I learned so much from BFG that I put to good use in filter-repo (which is much more than I can say for filter-branch), but keeping that section presented a few problems: * In order to recommend that people quit using filter-branch, we need to provide them a recomendation for something else to use that can handle all the same types of rewrites. To my knowledge, filter-repo is the only such tool. So it needs to be mentioned. * I don't want to give conflicting recommendations to users * If we recommend two tools, we shouldn't expect users to learn both and pick which one to use; we should explain which problems one can solve that the other can't or when one is much faster than the other. * BFG and filter-repo have similar performance * All filtering types that BFG can do, filter-repo can also do. In fact, filter-repo comes with a reimplementation of BFG named bfg-ish which provides the same user-interface as BFG but with several bugfixes and new features that are hard to implement in BFG due to its technical underpinnings. While I could still mention both tools, it seems like I would need to provide some kind of comparison and I would ultimately just say that filter-repo can do everything BFG can, so ultimately it seems that it is just better to remove that section altogether. Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2019-04-08gc docs: remove incorrect reference toÆvar Arnfjörð Bjarmason
The chance of a repository being corrupted due to a "gc" has nothing to do with whether or not that "gc" was invoked via "gc --auto", but whether there's other concurrent operations happening. This is already noted earlier in the paragraph, so there's no reason to suggest this here. The user can infer from the rest of the documentation that "gc" will run automatically unless is set, and we shouldn't confuse the issue by implying that "gc --auto" is somehow more prone to produce corruption than a normal "gc". Well, it is in the sense that a blocking "gc" would stop you from doing anything else in *that* particular terminal window, but users are likely to have another window, or to be worried about how concurrent "gc" on a server might cause corruption. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2019-04-08gc docs: clarify that "gc" doesn't throw away referenced objectsÆvar Arnfjörð Bjarmason
Amend the "NOTES" section to fix up wording that's been with us since 3ffb58be0a ("doc/git-gc: add a note about what is collected", 2008-04-23). I can't remember when/where anymore (I think Freenode #Git), but at some point I was having a conversation with someone who was convinced that "gc" would prune things only referenced by e.g. refs/pull/*, and pointed to this section as proof. It turned out that they'd read the "branches and tags" wording here and thought just refs/{heads,tags}/* and refs/remotes/* etc. would be kept, which is what we enumerate explicitly. So let's say "other refs", even though just above we say "objects that are referenced anywhere in your repository". Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2019-04-08gc docs: downplay the usefulness of --aggressiveÆvar Arnfjörð Bjarmason
The existing "gc --aggressive" docs come just short of recommending to users that they run it regularly. I've personally talked to many users who've taken these docs as an advice to use this option, and have, usually it's (mostly) a waste of time. So let's clarify what it really does, and let the user draw their own conclusions. Let's also clarify the "The effects [...] are persistent" to paraphrase a brief version of Jeff King's explanation at [1]. 1. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2019-04-08gc docs: include the "gc.*" section from "config" in "gc"Ævar Arnfjörð Bjarmason
Rather than duplicating the documentation for the various "gc" options let's include the "gc" docs from git-config. They were mostly better already, and now we don't have the same docs in two places with subtly different wording. In the cases where the git-gc(1) docs were saying something the "gc" docs in git-config(1) didn't cover move the relevant section over to the git-config(1) docs. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2019-03-24gc docs: clean grammar for "gc.bigPackThreshold"Ævar Arnfjörð Bjarmason
Clean up the grammar in the documentation for "gc.bigPackThreshold". This documentation was added in 9806f5a7bf ("gc --auto: exclude base pack if not enough mem to "repack -ad"", 2018-04-15). Saying "the amount of memory estimated for" flows more smoothly than the previous "the amount of memory is estimated not enough". Suggested-by: Jeff King <> Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2019-03-24gc docs: stop noting "repack" flagsÆvar Arnfjörð Bjarmason
Remove the mention of specific flags from the "gc" documentation, and leave it at describing what we'll do instead. As seen in builtin/gc.c we'll use various repack flags depending on what we detect we need to do, so this isn't always accurate. More importantly, a subsequent change is about to remove all this documentation and replace it with an include of the gc.* docs in git-config(1). By first changing this it's easier to reason about that subsequent change. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2019-03-24gc docs: modernize the advice for manually running "gc"Ævar Arnfjörð Bjarmason
The docs have been recommending that users need to run this manually, but that hasn't been needed in practice for a long time except in exceptional circumstances. Let's instead have this reflect reality and say that most users don't need to run this manually at all, while briefly describing the sorts sort of cases where "gc" does need to be run manually. Since we're recommending that users run this most of the and usually don't need to tweak it, let's tone down the very prominent example of the command. It's sufficient to point to the documentation below. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2019-03-11Merge branch 'rd/gc-prune-doc-fix'Junio C Hamano
Doxfix. * rd/gc-prune-doc-fix: docs/git-gc: fix typo "--prune=all" to "--prune=now"
2019-03-03docs/git-gc: fix typo "--prune=all" to "--prune=now"Robert P. J. Day
Signed-off-by: Robert P. J. Day <> Signed-off-by: Junio C Hamano <>
2019-01-08git-gc.txt: fix typo about gc.writeCommitGraphDerrick Stolee
Reported-by: Stefan Haller <> Signed-off-by: Derrick Stolee <> Signed-off-by: Junio C Hamano <>
2018-10-11gc doc: mention the commit-graph in the introÆvar Arnfjörð Bjarmason
Explicitly mention in the intro that we may be writing supplemental data structures such as the commit-graph during "gc", i.e. to call out the "optimize" part of what this command does, it doesn't just "collect garbage" as the "gc" name might imply. Past changes have updated the intro to reflect new commands, such as mentioning "worktree" in b586a96a39 ("gc.txt: more details about what gc does", 2018-03-15). So let's elaborate on what was added in d5d5d7b641 ("gc: automatically write commit-graph files", 2018-06-27). See also (follow-up replies) for an on-list discussion about what "gc" does. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-06-27gc: automatically write commit-graph filesDerrick Stolee
The commit-graph file is a very helpful feature for speeding up git operations. In order to make it more useful, make it possible to write the commit-graph file during standard garbage collection operations. Add a 'gc.commitGraph' config setting that triggers writing a commit-graph file after any non-trivial 'git gc' command. Defaults to false while the commit-graph feature matures. We specifically do not want to have this on by default until the commit-graph feature is fully integrated with history-modifying features like shallow clones. Helped-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Derrick Stolee <> Signed-off-by: Junio C Hamano <>
2018-05-23Merge branch 'nd/doc-header'Junio C Hamano
Doc formatting fix. * nd/doc-header: doc: keep first level section header in upper case
2018-05-23Merge branch 'nd/repack-keep-pack'Junio C Hamano
"git gc" in a large repository takes a lot of time as it considers to repack all objects into one pack by default. The command has been taught to pretend as if the largest existing packfile is marked with ".keep" so that it is left untouched while objects in other packs and loose ones are repacked. * nd/repack-keep-pack: pack-objects: show some progress when counting kept objects gc --auto: exclude base pack if not enough mem to "repack -ad" gc: handle a corner case in gc.bigPackThreshold gc: add gc.bigPackThreshold config gc: add --keep-largest-pack option repack: add --keep-pack option t7700: have closing quote of a test at the beginning of line
2018-05-08Merge branch 'sg/doc-gc-quote-mismatch-fix'Junio C Hamano
Doc formatting fix. * sg/doc-gc-quote-mismatch-fix: docs/git-gc: fix minor rendering issue
2018-05-02doc: keep first level section header in upper caseNguyễn Thái Ngọc Duy
When formatted as a man page, 1st section header is always in upper case even if we write it otherwise. Make all 1st section headers uppercase to keep it close to the final output. This does affect html since case is kept there, but I still think it's a good idea to maintain a consistent style for 1st section headers. Some sections perhaps should become second sections instead, where case is kept, and for better organization. I will update if anyone has suggestions about this. While at there I also make some header more consistent (e.g. examples vs example) and fix a couple minor things here and there. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-04-18docs/git-gc: fix minor rendering issueSZEDER Gábor
An unwanted single quote character in the paragraph documenting the 'gc.aggressiveWindow' config variable prevented the name of that config variable from being rendered correctly, ever since that piece of docs was added in 0d7566a5ba (Add --aggressive option to 'git gc', 2007-05-09). Remove that single quote. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2018-04-16gc --auto: exclude base pack if not enough mem to "repack -ad"Nguyễn Thái Ngọc Duy
pack-objects could be a big memory hog especially on large repos, everybody knows that. The suggestion to stick a .keep file on the giant base pack to avoid this problem is also known for a long time. Recent patches add an option to do just this, but it has to be either configured or activated manually. This patch lets `git gc --auto` activate this mode automatically when it thinks `repack -ad` will use a lot of memory and start affecting the system due to swapping or flushing OS cache. gc --auto decides to do this based on an estimation of pack-objects memory usage, which is quite accurate at least for the heap part, and whether that fits in half of system memory (the assumption here is for desktop environment where there are many other applications running). This mechanism only kicks in if gc.bigBasePackThreshold is not configured. If it is, it is assumed that the user already knows what they want. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-04-16gc: add gc.bigPackThreshold configNguyễn Thái Ngọc Duy
The --keep-largest-pack option is not very convenient to use because you need to tell gc to do this explicitly (and probably on just a few large repos). Add a config key that enables this mode when packs larger than a limit are found. Note that there's a slight behavior difference compared to --keep-largest-pack: all packs larger than the threshold are kept, not just the largest one. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-04-16gc: add --keep-largest-pack optionNguyễn Thái Ngọc Duy
This adds a new repack mode that combines everything into a secondary pack, leaving the largest pack alone. This could help reduce memory pressure. On linux-2.6.git, valgrind massif reports 1.6GB heap in "pack all" case, and 535MB in "pack all except the base pack" case. We save roughly 1GB memory by excluding the base pack. This should also lower I/O because we don't have to rewrite a giant pack every time (e.g. for linux-2.6.git that's a 1.4GB pack file).. PS. The use of string_list here seems overkill, but we'll need it in the next patch... Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-03-15gc.txt: more details about what gc doesNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2017-02-24docs/git-gc: fix default value for `--aggressiveDepth`Patrick Steinhardt
In commit 07e7dbf0d (gc: default aggressive depth to 50, 2016-08-11), the default aggressive depth of git-gc has been changed to 50. While git-config(1) has been updated to represent the new default value, git-gc(1) still mentions the old value. This patch fixes it. Signed-off-by: Patrick Steinhardt <> Reviewed-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-01-17Merge branch 'mm/gc-safety-doc' into maintJunio C Hamano
Doc update. * mm/gc-safety-doc: git-gc.txt: expand discussion of races with other processes
2016-11-16git-gc.txt: expand discussion of races with other processesMatt McCutchen
In general, "git gc" may delete objects that another concurrent process is using but hasn't created a reference to. Git has some mitigations, but they fall short of a complete solution. Document this in the git-gc(1) man page and add a reference from the documentation of the gc.pruneExpire config variable. Based on a write-up by Jeff King: Signed-off-by: Matt McCutchen <> Signed-off-by: Junio C Hamano <>
2016-06-08doc: change configuration variables formatTom Russello
This change configuration variables that where in italic style to monospace font according to the guideline. It was obtained with grep '[[:alpha:]]*\.[[:alpha:]]*::$' config.txt | \ sed -e 's/::$//' -e 's/\./\\\\./' | \ xargs -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt Signed-off-by: Tom Russello <> Signed-off-by: Erwan Mathoniere <> Signed-off-by: Samuel Groot <> Signed-off-by: Matthieu Moy <> Reviewed-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2015-10-16Merge branch 'jc/doc-gc-prune-now'Junio C Hamano
"git gc" is safe to run anytime only because it has the built-in grace period to protect young objects. In order to run with no grace period, the user must make sure that the repository is quiescent. * jc/doc-gc-prune-now: Documentation/gc: warn against --prune=<now>
2015-10-14Documentation/gc: warn against --prune=<now>Junio C Hamano
"git gc" is safe to run anytime only because it has the built-in grace period to protect objects that are created by other processes that are waiting for ref updates to anchor them to the history. In order to run with no grace period, the user must make sure that the repository is quiescent. Reviewed-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2015-03-14*config.txt: stick to camelCase naming conventionNguyễn Thái Ngọc Duy
This should improve readability. Compare "thislongname" and "thisLongName". The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Helped-by: Eric Sunshine <> Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Eric Sunshine <> Signed-off-by: Junio C Hamano <>
2014-03-31gc --aggressive: make --depth configurableNguyễn Thái Ngọc Duy
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 <> Subject: Re: [PATCH] gc --aggressive: make it really aggressive Date: Thu, 6 Dec 2007 08:19:24 -0800 (PST) Message-ID: <> Gmane-URL: 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 <> Signed-off-by: Junio C Hamano <>
2013-09-04Merge branch 'nd/gc-lock-against-each-other'Junio C Hamano
* nd/gc-lock-against-each-other: gc: reject if another gc is running, unless --force is given
2013-08-09gc: reject if another gc is running, unless --force is givenNguyễn Thái Ngọc Duy
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 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 <> Signed-off-by: Junio C Hamano <>
2013-04-18git-gc.txt, git-reflog.txt: document new expiry optionsMichael Haggerty
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 <> Signed-off-by: Junio C Hamano <>
2012-04-26docs: stop using asciidoc no-inline-literalJeff King
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 <>` used to erroneously auto-generate a mailto footnote for - 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 <> Signed-off-by: Junio C Hamano <>
2011-07-06Documentation: use [verse] for SYNOPSIS sectionsMartin von Zweigbergk
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 <> Signed-off-by: Junio C Hamano <>
2011-03-11doc: drop author/documentation sections from most pagesJeff King
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.
2010-12-20Merge branch 'maint'Junio C Hamano
* 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.
2010-12-17Fix typo in git-gc document.Jiang Xin
The variable gc.packrefs for git-gc can be set to true, false and "notbare", not "nobare". Signed-off-by: Jiang Xin <> Signed-off-by: Junio C Hamano <>
2010-11-03Change remote tracking to remote-tracking in non-trivial placesMatthieu Moy
To complement the straightforward perl application in previous patch, this adds a few manual changes. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2010-07-05Merge branch 'maint'Junio C Hamano
* maint: t0006: test timezone parsing rerere.txt: Document forget subcommand Documentation/git-gc.txt: add reference to githooks
2010-07-02Documentation/git-gc.txt: add reference to githooksChris Packham
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 <> Signed-off-by: Junio C Hamano <>
2010-05-21Merge branch 'jc/maint-no-reflog-expire-unreach-for-head'Junio C Hamano
* 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
2010-04-14Document gc.<pattern>.reflogexpire variablesJunio C Hamano
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 <>
2010-01-10Documentation: spell 'git cmd' without dash throughoutThomas Rast
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.
2010-01-10Documentation: format full commands in typewriter fontThomas Rast
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 <>
2009-10-20Documentation/git-gc.txt: change "references" to "reference"Matt Kraai
Signed-off-by: Matt Kraai <> Signed-off-by: Junio C Hamano <>
2009-09-29Documentation/git-gc.txt: default --aggressive window is 250, not 10Brandon Casey
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 <> Signed-off-by: Shawn O. Pearce <>
2009-08-28Fix overridable written with an extra 'e'Nanako Shiraishi
Signed-off-by: Nanako Shiraishi <> Signed-off-by: Junio C Hamano <>
2009-02-15gc: make --prune useful again by accepting an optional parameterJohannes Schindelin
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 <> Signed-off-by: Junio C Hamano <>
2008-07-05manpages: italicize git command names (which were in teletype font)Jonathan Nieder
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 <> Signed-off-by: Junio C Hamano <>