aboutsummaryrefslogtreecommitdiff
path: root/Documentation/git-fsck.txt
Commit message (Collapse)AuthorAge
* fsck: default to "git fsck --full"Junio C Hamano2009-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* doc/git-fsck: change the way for getting heads' SHA1sMarkus Heidelberg2008-12-21
| | | | | | | | | 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>
* manpages: italicize nongit command names (if they are in teletype font)Jonathan Nieder2008-07-05
| | | | | | | | | | | | | 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>
* 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>
* Documentation: point git-prune users to git-gcJeff King2008-04-29
| | | | | | | | | | | | | 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>
* 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>
* fsck --lost-found: write blob's contents, not their SHA-1Johannes Schindelin2007-07-22
| | | | | | | | | | 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>
* fsck --lost-found writes to subdirectories in .git/lost-found/Jonas Fonseca2007-07-03
| | | | | Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-fsck: add --lost-found optionJohannes Schindelin2007-07-02
| | | | | | | | | | | 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>
* War on whitespaceJunio C Hamano2007-06-07
| | | | | | | | | 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>
* git-fsck: learn about --verboseJohannes Schindelin2007-06-04
| | | | | | | 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>
* Fix lost-found to show commits only referenced by reflogsShawn O. Pearce2007-04-05
| | | | | | | | | | | | | | | | | | | | | | 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>
* git-fsck-objects is now synonym to git-fsckJunio C Hamano2007-01-28
Signed-off-by: Junio C Hamano <junkio@cox.net>