summaryrefslogtreecommitdiff
path: root/Documentation/git-read-tree.txt
AgeCommit message (Collapse)AuthorFilesLines
2018-01-23Merge branch 'as/read-tree-prefix-doc-fix'Libravatar Junio C Hamano1-3/+2
Doc update. * as/read-tree-prefix-doc-fix: doc/read-tree: remove obsolete remark
2018-01-09doc/read-tree: remove obsolete remarkLibravatar Andreas G. Schacker1-3/+2
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 <andreas.schacker@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-28Merge branch 'jk/doc-read-tree-table-asciidoctor-fix'Libravatar Junio C Hamano1-0/+2
A docfix. * jk/doc-read-tree-table-asciidoctor-fix: doc: put literal block delimiter around table
2017-09-24doc: put literal block delimiter around tableLibravatar Jeff King1-0/+2
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 git-scm.com), 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: https://github.com/git/git-scm.com/issues/1023 Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-29Merge branch 'ja/do-not-ask-needless-questions'Libravatar Junio C Hamano1-1/+1
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 aleckLibravatar Jean-Noel Avila1-1/+1
"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 <jn.avila@free.fr> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-16builtin/read-tree: add --recurse-submodules switchLibravatar Stefan Beller1-0/+6
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 <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21Documentation: use "command-line" when used as a compound adjective, and fix ↵Libravatar Jason St. John1-1/+1
other minor grammatical issues Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31Documentation: fix misuses of "nor"Libravatar Justin Lebar1-1/+1
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-06Merge branch 'jh/fetch-head-update'Libravatar Junio C Hamano1-1/+1
* jh/fetch-head-update: write first for-merge ref to FETCH_HEAD first
2012-01-03write first for-merge ref to FETCH_HEAD firstLibravatar Joey Hess1-1/+1
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 <joey@kitenet.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-01Documentation: read-tree --prefix works with existing subtreesLibravatar Clemens Buchacher1-5/+4
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 <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-26Merge branch 'nd/sparse-doc' into maint-1.7.6Libravatar Junio C Hamano1-2/+2
* nd/sparse-doc: git-read-tree.txt: update sparse checkout examples
2011-10-26Merge branch 'mg/maint-doc-sparse-checkout' into maint-1.7.6Libravatar Junio C Hamano1-24/+24
* 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'Libravatar Junio C Hamano1-2/+2
* nd/sparse-doc: git-read-tree.txt: update sparse checkout examples
2011-10-05Merge branch 'mg/maint-doc-sparse-checkout'Libravatar Junio C Hamano1-24/+24
* 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 examplesLibravatar Nguyễn Thái Ngọc Duy1-2/+2
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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-21git-read-tree.txt: correct sparse-checkout and skip-worktree descriptionLibravatar Michael J Gruber1-4/+4
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 <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-21git-read-tree.txt: language and typography fixesLibravatar Michael J Gruber1-20/+20
Fix a few missing articles and such, and mark-up 'commands' and `files` appropriately. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-06Documentation: use [verse] for SYNOPSIS sectionsLibravatar Martin von Zweigbergk1-0/+1
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>
2011-05-25Teach read-tree the -n|--dry-run optionLibravatar Jens Lehmann1-0/+5
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/lib-read-tree.sh 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 <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-9/+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-22Merge branch 'nd/maint-fix-add-typo-detection'Libravatar Junio C Hamano1-7/+0
* 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-11-30unpack-trees: fix sparse checkout's "unable to match directories"Libravatar Nguyễn Thái Ngọc Duy1-7/+0
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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-10read-tree: deprecate syntax without tree-ish argsLibravatar Jan Krüger1-1/+5
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 <jk@jk.gs> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-25git-read-tree.txt: acknowledge the directory matching bug in sparse checkoutLibravatar Nguyễn Thái Ngọc Duy1-0/+7
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-15Documentation/git-read-tree: clarify 2-tree mergeLibravatar Michael J Gruber1-13/+15
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 <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-15Documentation/git-read-tree: fix table layoutLibravatar Michael J Gruber1-10/+10
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 <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge remote branch 'remotes/trast-doc/for-next'Libravatar Junio C Hamano1-21/+21
* 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'Libravatar Junio C Hamano1-1/+51
* 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/t7002-grep.sh
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-21/+21
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-24Use 'fast-forward' all over the placeLibravatar Felipe Contreras1-1/+1
It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-23read-tree: add --no-sparse-checkout to disable sparse checkout supportLibravatar Nguyễn Thái Ngọc Duy1-1/+5
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-23unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkoutLibravatar Nguyễn Thái Ngọc Duy1-1/+3
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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-23Introduce "sparse checkout"Libravatar Nguyễn Thái Ngọc Duy1-0/+44
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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-27read-tree: migrate to parse-optionsLibravatar Stephen Boyd1-1/+4
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 <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-30Correct typos in RelNotes-1.6.1Libravatar Ralf Wildenhues1-1/+1
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-09checkout: do not lose staged removalLibravatar Junio C Hamano1-1/+10
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: http://thread.gmane.org/gmane.comp.version-control.git/4641/focus=4646 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 <gitster@pobox.com>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-21/+21
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-7/+7
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-16/+16
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-09Merge branch 'maint'Libravatar Junio C Hamano1-0/+3
* maint: git-read-tree: document -v option. Remove exec bit from builtin-fast-export.c
2008-06-09git-read-tree: document -v option.Libravatar Miklos Vajna1-0/+3
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> 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-05-28Manual subsection to refer to other pages is SEE ALSOLibravatar Junio C Hamano1-1/+1
Consistently say so in all caps as it is customary to do so. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-06Documentation: rename gitlink macro to linkgitLibravatar Dan McGee1-4/+4
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-06-16Document git read-tree --trivialLibravatar Jakub Narebski1-1/+7
Signed-off-by: Jakub Narebski <jnareb@gmail.com> 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-02Create a new manpage for the gitignore format, and reference it elsewhereLibravatar Josh Triplett1-1/+2
Only git-ls-files(1) describes the gitignore format in detail, and it does so with reference to git-ls-files options. Most users don't use the plumbing command git-ls-files directly, and shouldn't have to look in its manpage for information on the gitignore format. Create a new manpage gitignore(5) (Documentation/gitignore.txt), and factor out the gitignore documentation into that file, changing it to refer to .gitignore and $GIT_DIR/info/exclude as used by porcelain commands. Reference gitignore(5) from other relevant manpages and documentation. Remove now-redundant information on exclude patterns from git-ls-files(1), leaving only information on how git-ls-files options specify exclude patterns and what precedence they have. Signed-off-by: Josh Triplett <josh@freedesktop.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-03git-read-tree --index-output=<file>Libravatar Junio C Hamano1-1/+13
This corrects the interface mistake of the previous one, and gives a command line parameter to the only plumbing command that currently needs it: "git-read-tree". We can add the calls to set_alternate_index_output() to other plumbing commands that update the index if/when needed. Signed-off-by: Junio C Hamano <junkio@cox.net>