path: root/Documentation/git-read-tree.txt
AgeCommit message (Collapse)Author
2020-04-06doc: --recurse-submodules mostly applies to active submodulesDamien Robert
The documentation refers to "initialized" or "populated" submodules, to explain which submodules are affected by '--recurse-submodules', but the real terminology here is 'active' submodules. Update the documentation accordingly. Some terminology: - Active is defined in gitsubmodules(7), it only involves the configuration variables '', 'submodule.<name>.active' and 'submodule.<name>.url'. The function submodule.c::is_submodule_active checks that a submodule is active. - Populated means that the submodule's working tree is present (and the gitfile correctly points to the submodule repository), i.e. either the superproject was cloned with ` --recurse-submodules`, or the user ran `git submodule update --init`, or `git submodule init [<path>]` and `git submodule update [<path>]` separately which populated the submodule working tree. This does not involve the 3 configuration variables above. - Initialized (at least in the context of the man pages involved in this patch) means both "populated" and "active" as defined above, i.e. what `git submodule update --init` does. The --recurse-submodules option mostly affects active submodules. An exception is `git fetch` where the option affects populated submodules. As a consequence, in `git pull --recurse-submodules` the fetch affects populated submodules, but the resulting working tree update only affects active submodules. In the documentation of `git-pull`, let's distinguish between the fetching part which affects populated submodules, and the updating of worktrees, which only affects active submodules. Signed-off-by: Damien Robert <> Helped-by: Philippe Blain <> Signed-off-by: Junio C Hamano <>
2020-04-06doc: document --recurse-submodules for reset and restoreDamien Robert
Also unify the formulation about --no-recurse-submodules for checkout and switch, which we reuse for restore. And correct the formulation about submodules' HEAD in read-tree, which we reuse in reset. Signed-off-by: Damien Robert <> Signed-off-by: Junio C Hamano <>
2019-11-22sparse-checkout: create builtin with 'list' subcommandDerrick Stolee
The sparse-checkout feature is mostly hidden to users, as its only documentation is supplementary information in the docs for 'git read-tree'. In addition, users need to know how to edit the .git/info/sparse-checkout file with the right patterns, then run the appropriate 'git read-tree -mu HEAD' command. Keeping the working directory in sync with the sparse-checkout file requires care. Begin an effort to make the sparse-checkout feature a porcelain feature by creating a new 'git sparse-checkout' builtin. This builtin will be the preferred mechanism for manipulating the sparse-checkout file and syncing the working directory. The documentation provided is adapted from the "git read-tree" documentation with a few edits for clarity in the new context. Extra sections are added to hint toward a future change to a more restricted pattern set. Helped-by: Elijah Newren <> Signed-off-by: Derrick Stolee <> Signed-off-by: Junio C Hamano <>
2019-04-25Merge branch 'nd/checkout-m'Junio C Hamano
"git checkout -m <other>" was about carrying the differences between HEAD and the working-tree files forward while checking out another branch, and ignored the differences between HEAD and the index. The command has been taught to abort when the index and the HEAD are different. * nd/checkout-m: checkout: prevent losing staged changes with --merge read-tree: add --quiet unpack-trees: rename "gently" flag to "quiet" unpack-trees: keep gently check inside add_rejected_path
2019-04-02read-tree.txt: clarify --reset and worktree changesNguyễn Thái Ngọc Duy
The description of --reset stays true to the first implementation in 438195cced (git-read-tree: add "--reset" flag, 2005-06-09). That is, --reset discards unmerged entries. Or at least true to the commit message because I can't be sure about read-tree's behavior regarding local changes. But in fcc387db9b (read-tree -m -u: do not overwrite or remove untracked working tree files., 2006-05-17), it is clear that "-m -u" tries to keep local changes, while --reset is singled out and will keep overwriting worktree files. It's not stated in the commit message, but it's obvious from the patch. I went this far back not because I had a lot of free time, but because I did not trust my reading of unpack-trees.c code. So far I think the related changes in history agree with my understanding of the current code, that "--reset" loses local changes. This behavior is not mentioned in git-read-tree.txt, even though old-timers probably can just guess it based on the "reset" name. Update git-read-tree.txt about this. Side note. There's another change regarding --reset that is not obviously about local changes, b018ff6085 (unpack-trees: fix "read-tree -u --reset A B" with conflicted index, 2012-12-29). But I'm pretty sure this is about the first function of --reset, to discard unmerged entries correctly. PS. The patch changes one more line than necessary because the first line uses spaces instead of tab. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-03-24read-tree: add --quietNguyễn Thái Ngọc Duy
read-tree is basically the front end of unpack-trees code and shoud expose all of its functionality (unless it's designed for internal use). This "opts.quiet" (formerly "opts.gently") was added for builtin/checkout.c but there is no reason why other read-tree users won't find this useful. The test that is updated to run 'read-tree --quiet' was added because unpack-trees was accidentally not being quiet [1] in 6a143aa2b2 (checkout -m: attempt merge when deletion of path was staged - 2014-08-12). Because checkout is the only "opts.quiet" user, there was no other way to test quiet behavior. But we can now test it directly. 6a143aa2b2 was manually reverted to verify that read-tree --quiet works correctly (i.e. test_must_be_empty fails). [1] the commit message there say "errors out instead of performing a merge" but I'm pretty sure the "performing a merge" happens anyway even before that commit. That line should say "errors out _in addition to_ performing a merge" Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
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-01-23Merge branch 'as/read-tree-prefix-doc-fix'Junio C Hamano
Doc update. * as/read-tree-prefix-doc-fix: doc/read-tree: remove obsolete remark
2018-01-09doc/read-tree: remove obsolete remarkAndreas G. Schacker
Earlier versions of `git read-tree` required the `--prefix` option value to end with a slash. This restriction was eventually lifted without a corresponding amendment to the documentation. Signed-off-by: Andreas G. Schacker <> Signed-off-by: Junio C Hamano <>
2017-09-28Merge branch 'jk/doc-read-tree-table-asciidoctor-fix'Junio C Hamano
A docfix. * jk/doc-read-tree-table-asciidoctor-fix: doc: put literal block delimiter around table
2017-09-24doc: put literal block delimiter around tableJeff King
The git-read-tree manpage has a table that is meant to be shown with its spacing exactly as it is in the source. We mark it as a "literal paragraph" by indenting each line by at least one space. This renders OK with asciidoc for both the HTML and manpage versions. But there are two problems when we render it with asciidoctor. The first is that some lines mix tabs and spaces. Even if asciidoctor is correctly configured for 8-space tabs, it seems to handle this case differently, soaking up some of the initial literal-paragraph spaces and mis-aligning the table text. The second problem is that the table uses blank lines to group rows. But as blank lines separate paragraphs in asciidoc, this actually means that each chunk of the table is rendered in its own pre-formatted <div> block. This happens even with vanilla asciidoc, but there's no visible result because the literal paragraphs aren't styled in any special way. But with asciidoctor (or at least the styles used on, literal paragraphs are styled with a different background. This breaks the table into a visually distracting sequence of chunks. We can fix both by adding a literal-paragraph block delimiter. That turns the whole table into a single block (for both implementations) and causes asciidoctor to render the indentation as it is in the source. Reported-at: Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-05-29Merge branch 'ja/do-not-ask-needless-questions'Junio C Hamano
Git sometimes gives an advice in a rhetorical question that does not require an answer, which can confuse new users and non native speakers. Attempt to rephrase them. * ja/do-not-ask-needless-questions: git-filter-branch: be more direct in an error message read-tree -m: make error message for merging 0 trees less smart aleck usability: don't ask questions if no reply is required
2017-05-12read-tree -m: make error message for merging 0 trees less smart aleckJean-Noel Avila
"git read-tree -m" requires a tree argument to name the tree to be merged in. Git uses a cutesy error message to say so and why: $ git read-tree -m warning: read-tree: emptying the index with no arguments is deprecated; use --empty fatal: just how do you expect me to merge 0 trees? $ git read-tree -m --empty fatal: just how do you expect me to merge 0 trees? When lucky, that could produce an ah-hah moment for the user, but it's more likely to irritate and distract them. Instead, tell the user plainly that the tree argument is required. Also document this requirement in the git-read-tree(1) manpage where there is room to explain it in a more straightforward way. Signed-off-by: Jean-Noel Avila <> Helped-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2017-03-16builtin/read-tree: add --recurse-submodules switchStefan Beller
A new known failure mode is introduced[1], which is actually not a failure but a feature in read-tree. Unlike checkout for which the recursive submodule tests were originally written, read-tree does warn about ignored untracked files that would be overwritten. For the sake of keeping the test library for submodules generic, just mark the test as a failure. [1] KNOWN_FAILURE_SUBMODULE_OVERWRITE_IGNORED_UNTRACKED Signed-off-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>
2014-05-21Documentation: use "command-line" when used as a compound adjective, and fix ↵Jason St. John
other minor grammatical issues Signed-off-by: Jason St. John <> Signed-off-by: Junio C Hamano <>
2014-03-31Documentation: fix misuses of "nor"Justin Lebar
Signed-off-by: Justin Lebar <> Signed-off-by: Junio C Hamano <>
2012-01-06Merge branch 'jh/fetch-head-update'Junio C Hamano
* jh/fetch-head-update: write first for-merge ref to FETCH_HEAD first
2012-01-04write first for-merge ref to FETCH_HEAD firstJoey Hess
The FETCH_HEAD refname is supposed to refer to the ref that was fetched and should be merged. However all fetched refs are written to .git/FETCH_HEAD in an arbitrary order, and resolve_ref_unsafe simply takes the first ref as the FETCH_HEAD, which is often the wrong one, when other branches were also fetched. The solution is to write the for-merge ref(s) to FETCH_HEAD first. Then, unless --append is used, the FETCH_HEAD refname behaves as intended. If the user uses --append, they presumably are doing so in order to preserve the old FETCH_HEAD. While we are at it, update an old example in the read-tree documentation that implied that each entry in FETCH_HEAD only has the object name, which is not true for quite a while. [jc: adjusted tests] Signed-off-by: Joey Hess <> Signed-off-by: Junio C Hamano <>
2012-01-01Documentation: read-tree --prefix works with existing subtreesClemens Buchacher
Since 34110cd4 (Make 'unpack_trees()' have a separate source and destination index) it is no longer true that a subdirectory with the same prefix must not exist. Signed-off-by: Clemens Buchacher <> Signed-off-by: Junio C Hamano <>
2011-10-26Merge branch 'nd/sparse-doc' into maint-1.7.6Junio C Hamano
* nd/sparse-doc: git-read-tree.txt: update sparse checkout examples
2011-10-26Merge branch 'mg/maint-doc-sparse-checkout' into maint-1.7.6Junio C Hamano
* mg/maint-doc-sparse-checkout: git-read-tree.txt: correct sparse-checkout and skip-worktree description git-read-tree.txt: language and typography fixes unpack-trees: print "Aborting" to stderr
2011-10-10Merge branch 'nd/sparse-doc'Junio C Hamano
* nd/sparse-doc: git-read-tree.txt: update sparse checkout examples
2011-10-05Merge branch 'mg/maint-doc-sparse-checkout'Junio C Hamano
* mg/maint-doc-sparse-checkout: git-read-tree.txt: correct sparse-checkout and skip-worktree description git-read-tree.txt: language and typography fixes unpack-trees: print "Aborting" to stderr
2011-09-26git-read-tree.txt: update sparse checkout examplesNguyễn Thái Ngọc Duy
The negation example uses '*' to match everything. This used to work before 9037026 (unpack-trees: fix sparse checkout's "unable to match directories") because back then, the list of paths is used to match sparse patterns, so with the patterns * !subdir/ subdir/ always matches any path that start with subdir/ and "*" has no chance to get tested. The result is subdir is excluded. After the said commit, a tree structure is dynamically created and sparse pattern matching now follows closely how read_directory() applies .gitignore. This solves one problem, but reveals another one. With this new strategy, "!subdir/" rule will be only tested once when "subdir" directory is examined. Entries inside subdir, when examined, will match "*" and are (correctly) re-added again because any rules without a slash will match at every directory level. In the end, "*" can revert every negation rules. In order to correctly exclude subdir, we must use /* !subdir to limit "match all" rule at top level only. "*" rule has no actual use in sparse checkout and can be confusing to users. While we can automatically turn "*" to "/*", this violates .gitignore definition. Instead, discourage "*" in favor of "/*" (in the second example). Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2011-09-21git-read-tree.txt: correct sparse-checkout and skip-worktree descriptionMichael J Gruber
The description of .git/info/sparse-checkout and skip-worktree is exactly the opposite of what is true, which is: If a file matches a pattern in sparse-checkout, then (it is to be checked out and therefore) skip-worktree is unset for that file; otherwise, it is set (so that it is not checked out). Currently, the opposite is documented, and (consistently) read-tree's behavior with respect to bit flips is descibed incorrectly. Fix it. In hindsight, it would have been much better to have a "sparse-ignore" or "sparse-skip" file so that an empty file would mean a full checkout, and the file logic would be analogous to that of .gitignore, excludes and skip-worktree. Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2011-09-21git-read-tree.txt: language and typography fixesMichael J Gruber
Fix a few missing articles and such, and mark-up 'commands' and `files` appropriately. Signed-off-by: Michael J Gruber <> 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-05-25Teach read-tree the -n|--dry-run optionJens Lehmann
The option can be used to check if read-tree with the same set of other options like "-m" and "-u" would succeed without actually changing either the index or the working tree. The relevant tests in the t10?? range were extended to do a read-tree -n before the real read-tree to make sure neither the index nor any local files were changed with -n and the same exit code as without -n is returned. The helper functions added for that purpose reside in the new t/ file. The only exception is #13 in t1004 ("unlinking an un-unlink-able symlink"). As this is an issue of wrong directory permissions it is not detected with -n. Signed-off-by: Jens Lehmann <> 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-22Merge branch 'nd/maint-fix-add-typo-detection'Junio C Hamano
* nd/maint-fix-add-typo-detection: Revert "excluded_1(): support exclude files in index" unpack-trees: fix sparse checkout's "unable to match directories" unpack-trees: move all skip-worktree checks back to unpack_trees() dir.c: add free_excludes() cache.h: realign and use (1 << x) form for CE_* constants
2010-12-01unpack-trees: fix sparse checkout's "unable to match directories"Nguyễn Thái Ngọc Duy
Matching index entries against an excludes file currently has two problems. First, there's no function to do it. Code paths (like sparse checkout) that wanted to try it would iterate over index entries and for each index entry pass that path to excluded_from_list(). But that is not how excluded_from_list() works; one is supposed to feed in each ancester of a path before a given path to find out if it was excluded because of some parent or grandparent matching a bigsubdirectory/ pattern despite the path not matching any .gitignore pattern directly. Second, it's inefficient. The excludes mechanism is supposed to let us block off vast swaths of the filesystem as uninteresting; separately checking every index entry doesn't fit that model. Introduce a new function to take care of both these problems. This traverses the index in depth-first order (well, that's what order the index is in) to mark un-excluded entries. Maybe some day the in-core index format will be restructured to make this sort of operation easier. Or maybe we will want to try some binary search based thing. The interface is simple enough to allow all those things. Example: clear_ce_flags(the_index.cache, the_index.cache_nr, CE_CANDIDATE, CE_CLEARME, exclude_list); would clear the CE_CLEARME flag on all index entries with CE_CANDIDATE flag and not matched by exclude_list. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2010-09-10read-tree: deprecate syntax without tree-ish argsJan Krüger
Currently, read-tree can be run without tree-ish arguments, in which case it will empty the index. Since this behavior is undocumented and perhaps a bit too invasive to be the "default" action for read-tree, deprecate it in favor of a new --empty option that does the same thing. Signed-off-by: Jan Krüger <> Signed-off-by: Junio C Hamano <>
2010-07-26git-read-tree.txt: acknowledge the directory matching bug in sparse checkoutNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2010-03-15Documentation/git-read-tree: clarify 2-tree mergeMichael J Gruber
Clarify the description of the 2-tree merge by defining the terms which are used in the table, and by applying some small linguistic changes. Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2010-03-15Documentation/git-read-tree: fix table layoutMichael J Gruber
Asciidoc takes the first non-space character in the first line of the paragraph as a reference point for preformatted layout, so adjust to that to make the table align. Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2010-01-21Merge remote branch 'remotes/trast-doc/for-next'Junio C Hamano
* remotes/trast-doc/for-next: Documentation: spell 'git cmd' without dash throughout Documentation: format full commands in typewriter font Documentation: warn prominently against merging with dirty trees Documentation/git-merge: reword references to "remote" and "pull" Conflicts: Documentation/config.txt Documentation/git-config.txt Documentation/git-merge.txt
2010-01-13Merge branch 'nd/sparse'Junio C Hamano
* nd/sparse: (25 commits) t7002: test for not using external grep on skip-worktree paths t7002: set test prerequisite "external-grep" if supported grep: do not do external grep on skip-worktree entries commit: correctly respect skip-worktree bit ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID tests: rename duplicate t1009 sparse checkout: inhibit empty worktree Add tests for sparse checkout read-tree: add --no-sparse-checkout to disable sparse checkout support unpack-trees(): ignore worktree check outside checkout area unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout unpack-trees.c: generalize verify_* functions unpack-trees(): add CE_WT_REMOVE to remove on worktree alone Introduce "sparse checkout" dir.c: export excluded_1() and add_excludes_from_file_1() excluded_1(): support exclude files in index unpack-trees(): carry skip-worktree bit over in merged_entry() Read .gitignore from index if it is skip-worktree Avoid writing to buffer in add_excludes_from_file_1() ... Conflicts: .gitignore Documentation/config.txt Documentation/git-update-index.txt Makefile entry.c t/
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.
2009-10-25Use 'fast-forward' all over the placeFelipe Contreras
It's a compound word. Signed-off-by: Felipe Contreras <> Signed-off-by: Junio C Hamano <>
2009-08-24read-tree: add --no-sparse-checkout to disable sparse checkout supportNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2009-08-24unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkoutNguyễn Thái Ngọc Duy
This patch introduces core.sparseCheckout, which will control whether sparse checkout support is enabled in unpack_trees() It also loads sparse-checkout file that will be used in the next patch. I split it out so the next patch will be shorter, easier to read. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2009-08-24Introduce "sparse checkout"Nguyễn Thái Ngọc Duy
With skip-worktree bit, you can manually set it to unwanted files, then remove them: you would have the so-called sparse checkout. The disadvantages are: - Porcelain tools are not aware of this. Everytime you do an operation that may update working directory, skip-worktree may be cleared out. You have to set them again. - You still have to remove skip-worktree'd files manually, which is boring and ineffective. These will be addressed in the following patches. This patch gives an idea what is "sparse checkout" in Documentation/git-read-tree.txt. This file is chosen instead of git-checkout.txt because it is quite technical and user-unfriendly. I'd expect git-checkout.txt to have something when Porcelain support is done. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2009-06-27read-tree: migrate to parse-optionsStephen Boyd
Cleanup the documentation to explicitly state that --exclude-directory is only meaningful when used with -u. Also make the documentation more consistent with the usage message printed with read-tree --help-all. The -m, --prefix, --reset options are performing similar actions (setting some flags, read_cache_unmerged(), checking for illegal option combinations). Instead of performing these actions when the options are parsed, we delay performing them until after parse-opts has finished. The bit fields in struct unpack_trees_options have been promoted to full unsigned ints. This is necessary to avoid "foo ? 1 : 0" constructs to set these fields. Signed-off-by: Stephen Boyd <> Signed-off-by: Junio C Hamano <>
2008-09-30Correct typos in RelNotes-1.6.1Ralf Wildenhues
Signed-off-by: Shawn O. Pearce <>
2008-09-10checkout: do not lose staged removalJunio C Hamano
The logic to checkout a different commit implements the safety to never lose user's local changes. For example, switching from a commit to another commit, when you have changed a path that is different between them, need to merge your changes to the version from the switched-to commit, which you may not necessarily be able to resolve easily. By default, "git checkout" refused to switch branches, to give you a chance to stash your local changes (or use "-m" to merge, accepting the risks of getting conflicts). This safety, however, had one deliberate hole since early June 2005. When your local change was to remove a path (and optionally to stage that removal), the command checked out the path from the switched-to commit nevertheless. This was to allow an initial checkout to happen smoothly (e.g. an initial checkout is done by starting with an empty index and switching from the commit at the HEAD to the same commit). We can tighten the rule slightly to allow this special case to pass, without losing sight of removal explicitly done by the user, by noticing if the index is truly empty when the operation begins. For historical background, see: This case is marked as *0* in the message, which both Linus and I said "it feels somewhat wrong but otherwise we cannot start from an empty index". 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 <>
2008-07-02Documentation formatting and cleanupJonathan Nieder
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 <> Signed-off-by: Junio C Hamano <>
2008-07-02Documentation: be consistent about "git-" versus "git "Jonathan Nieder
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 <> Signed-off-by: Junio C Hamano <>
2008-06-09Merge branch 'maint'Junio C Hamano
* maint: git-read-tree: document -v option. Remove exec bit from builtin-fast-export.c
2008-06-09git-read-tree: document -v option.Miklos Vajna
Signed-off-by: Miklos Vajna <> Signed-off-by: Junio C Hamano <>