kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Jeff King	5d2fc9135a	docs: put listed example commands in backticks Many examples of git command invocation are given in asciidoc listing blocks, which makes them monospaced and avoids further interpretation of special characters. Some manpages make a list of examples, like: git foo:: Run git foo. git foo -q:: Use the "-q" option. to quickly show many variants. However, they can sometimes be hard to read, because they are shown in a proportional-width font (so, for example, seeing the difference between "-- foo" and "--foo" can be difficult). This patch puts all such examples into backticks, which gives the equivalent formatting to a listing block (i.e., monospaced and without character interpretation). As a bonus, this also fixes an example in the git-push manpage, in which "git push origin :::" was accidentally considered a newly-indented list, and not a list item with "git push origin :" in it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jeff King	48bb914ed6	doc: drop author/documentation sections from most pages 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.	14 years ago
Bert Wesarg	3a15048d83	merge-file: add option to select union merge favor Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Bert Wesarg	11f3aa2305	merge-file: add option to specify the marker size This adds the abbility to specify the conflict marker size for merges outside a git repository. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Thomas Rast	0b444cdb19	Documentation: spell 'git cmd' without dash throughout 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.	15 years ago
Junio C Hamano	73eb40eeaa	git-merge-file --ours, --theirs Sometimes people want their conflicting merges autoresolved by favouring upstream changes. The standard answer they are given is to run "git diff --name-only \| xargs git checkout MERGE_HEAD --" in such a case. This is to accept automerge results for the paths that are fully resolved automatically, while taking their version of the file in full for paths that have conflicts. This is problematic on two counts. One is that this is not exactly what these people want. It discards all changes they did on their branch for any paths that conflicted. They usually want to salvage as much automerge result as possible in a conflicted file, and want to take the upstream change only in the conflicted part. This patch teaches two new modes of operation to the lowest-lever merge machinery, xdl_merge(). Instead of leaving the conflicted lines from both sides enclosed in <<<, ===, and >>> markers, the conflicts are resolved favouring our side or their side of changes. A larger problem is that this tends to encourage a bad workflow by allowing people to record such a mixed up half-merged result as a full commit without auditing. This commit does not tackle this issue at all. In git, we usually give long enough rope to users with strange wishes as long as the risky features are not enabled by default, and this is such a risky feature. Signed-off-by: Avery Pennarun <apenwarr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Ralf Wildenhues	29b802aae6	Improve language in git-merge.txt and related docs Improve some minor language and format issues like hyphenation, phrases, spacing, word order, comma, attributes. Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Jonathan Nieder	2fd02c92db	manpages: italicize nongit command names (if they are in teletype font) 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>	17 years ago
Jonathan Nieder	ba020ef5eb	manpages: italicize git command names (which were in teletype font) 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>	17 years ago
Jonathan Nieder	0979c10649	manpages: italicize command names This includes nongit commands like RCS 'merge'. This patch only italicizes names of commands if they had no formatting before. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Jonathan Nieder	483bc4f045	Documentation formatting and cleanup 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>	17 years ago
Jonathan Nieder	b1889c36d8	Documentation: be consistent about "git-" versus "git " 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>	17 years ago
Christian Couder	9e1f0a85c6	documentation: move git(7) to git(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>	17 years ago
Dan McGee	5162e69732	Documentation: rename gitlink macro to linkgit 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>	17 years ago
Junio C Hamano	c3f0baacad	Documentation: sync git.txt command list and manual page title Also reorders a handful entries to make each list sorted alphabetically. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	38477d9e60	Fix mis-mark-up in git-merge-file.txt documentation Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Johannes Schindelin	9abaa7f033	Document git-merge-file Most of this is derived from the documentation of RCS merge. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago

18 Commits (675a0fe297e88e0fab2ee9b311d4ebb3c3bfef28)