summaryrefslogtreecommitdiff
path: root/Documentation/git-fsck.txt
AgeCommit message (Collapse)AuthorFilesLines
2012-08-22Merge branch 'jc/tag-doc'Libravatar Junio C Hamano1-2/+2
Our documentation used to assume having files in .git/refs/* directories was the only to have branches and tags, but that is not true for quite some time. * jc/tag-doc: Documentation: do not mention .git/refs/* directories
2012-08-06Documentation: do not mention .git/refs/* directoriesLibravatar Junio C Hamano1-2/+2
It is an implementation detail that a new tag is created by adding a file in the .git/refs/tags directory. The only thing the user needs to know is that a "git tag" creates a ref in the refs/tags namespace, and without "-f", it does not overwrite an existing tag. Inspired by a report from 乙酸鋰 <ch3cooli@gmail.com>; I think I caught all the existing mention in Documentation/ directory in the tip of 1.7.9.X maintenance track, but we may have added new ones since then. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-05fsck doc: a minor typofixLibravatar Junio C Hamano1-1/+1
Reword the misspelled "squelch" noticed by Hermann Gaustere to say "omit", which would sit better anyway. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-28fsck: --no-dangling omits "dangling object" informationLibravatar Junio C Hamano1-1/+6
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-22Merge branch 'jk/doc-fsck'Libravatar Junio C Hamano1-18/+8
* jk/doc-fsck: docs: brush up obsolete bits of git-fsck manpage Conflicts: Documentation/git-fsck.txt
2011-12-16docs: brush up obsolete bits of git-fsck manpageLibravatar Jeff King1-18/+8
After the description and options, the fsck manpage contains some discussion about what it does. Over time, this discussion has become somewhat obsolete, both in content and formatting. In particular: 1. There are many options now, so starting the discussion with "It tests..." makes it unclear whether we are talking about the last option, or about the tool in general. Let's start a new "discussion" section and make our antecedent more clear. 2. It gave an example for --unreachable using for-each-ref to mention all of the heads, saying that it will do "a _lot_ of verification". This is hopelessly out-of-date, as giving no arguments will check much more (reflogs, the index, non-head refs). 3. It goes on to mention tests "to be added" (like tree object sorting). We now have these tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-06fsck: print progressLibravatar Nguyễn Thái Ngọc Duy1-1/+10
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-05-16Documentation/git-fsck.txt: fix typo: unreadable -> unreachableLibravatar Jim Meyering1-2/+2
Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-8/+0
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-18fsck docs: remove outdated and useless diagnosticLibravatar Mark Lodato1-3/+0
In git-fsck(1), there was a reference to the warning "<tree> has full pathnames in it". This exact wording has not been used since 2005 (commit f1f0d0889e55), when the wording was changed slightly. More importantly, the description of that warning was useless, and there were many other similar warning messages which were not document at all. Since all these warnings are fairly obvious, there is no need for them to be in the man page. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-2/+2
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.
2009-10-20fsck: default to "git fsck --full"Libravatar Junio C Hamano1-2/+3
Linus and other git developers from the early days trained their fingers to type the command, every once in a while even without thinking, to check the consistency of the repository back when the lower core part of the git was still being developed. Developers who wanted to make sure that git correctly dealt with packfiles could deliberately trigger their creation and checked them after they were created carefully, but loose objects are the ones that are written by various commands from random codepaths. It made some technical sense to have a mode that checked only loose objects from the debugging point of view for that reason. Even for git developers, there no longer is any reason to type "git fsck" every five minutes these days, worried that some newly created objects might be corrupt due to recent change to git. The reason we did not make "--full" the default is probably we trust our filesystems a bit too much. At least, we trusted filesystems more than we trusted the lower core part of git that was under development. Once a packfile is created and we always use it read-only, there didn't seem to be much point in suspecting that the underlying filesystems or disks may corrupt them in such a way that is not caught by the SHA-1 checksum over the entire packfile and per object checksum. That trust in the filesystems might have been a good tradeoff between fsck performance and reliability on platforms git was initially developed on and for, but it may not be true anymore as we run on many more platforms these days. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-21doc/git-fsck: change the way for getting heads' SHA1sLibravatar Markus Heidelberg1-1/+2
The straightforward way with using 'cat .git/refs/heads/*' doesn't work with packed refs as well as branches of the form topic/topic1. So let's use git-for-each-ref for getting the heads' SHA1s in this example. Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize nongit command names (if they are in teletype font)Libravatar Jonathan Nieder1-1/+1
Some manual pages use teletype font to set command names. We change them to use italics, instead. This creates a visual distinction between names of commands and command lines that can be typed at the command line. It is also more consistent with other man pages outside Git. In this patch, the commands named are non-git commands like bash. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-2/+2
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>
2008-07-01Documentation formatting and cleanupLibravatar Jonathan Nieder1-3/+3
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>
2008-07-01Documentation: be consistent about "git-" versus "git "Libravatar Jonathan Nieder1-2/+2
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>
2008-06-06documentation: move git(7) to git(1)Libravatar Christian Couder1-1/+1
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>
2008-04-29Documentation: point git-prune users to git-gcLibravatar Jeff King1-1/+2
Most users should be using git-gc instead of directly calling prune. For those who really do want more information on pruning, let's point them at git-fsck, which goes into slightly more detail on reachability. And since we're pointing users there, let's make sure reflogs are mentioned in git-fsck(1). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-06Documentation: rename gitlink macro to linkgitLibravatar Dan McGee1-1/+1
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>
2007-07-22fsck --lost-found: write blob's contents, not their SHA-1Libravatar Johannes Schindelin1-2/+4
When looking for a lost blob, it is much nicer to be able to grep through .git/lost-found/other/* than to write an inefficient loop over the file names. So write the contents of the dangling blobs, not their object names. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03fsck --lost-found writes to subdirectories in .git/lost-found/Libravatar Jonas Fonseca1-2/+2
Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02git-fsck: add --lost-found optionLibravatar Johannes Schindelin1-1/+5
With this option, dangling objects are not only reported, but also written to .git/lost-found/commit/ or .git/lost-found/other/. This option implies '--full' and '--no-reflogs'. 'git fsck --lost-found' is meant as a replacement for git-lost-found. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+0
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-04git-fsck: learn about --verboseLibravatar Johannes Schindelin1-1/+4
With --verbose, it gets really chatty now. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-05Fix lost-found to show commits only referenced by reflogsLibravatar Shawn O. Pearce1-1/+7
Prior to 1.5.0 the git-lost-found utility was useful to locate commits that were not referenced by any ref. These were often amends, or resets, or tips of branches that had been deleted. Being able to locate a 'lost' commit and recover it by creating a new branch was a useful feature in those days. Unfortunately 1.5.0 added the reflogs to the reachability analysis performed by git-fsck, which means that most commits users would consider to be lost are still reachable through a reflog. So most (or all!) commits are reachable, and nothing gets output from git-lost-found. Now git-fsck can be told to ignore reflogs during its reachability analysis, making git-lost-found useful again to locate commits that are no longer referenced by a ref itself, but may still be referenced by a reflog. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28git-fsck-objects is now synonym to git-fsckLibravatar Junio C Hamano1-0/+139
Signed-off-by: Junio C Hamano <junkio@cox.net>