summaryrefslogtreecommitdiff
path: root/Documentation/git-revert.txt
AgeCommit message (Collapse)AuthorFilesLines
2011-08-08revert: Introduce --continue to continue the operationLibravatar Ramkumar Ramachandra1-0/+1
Introduce a new "git cherry-pick --continue" command which uses the information in ".git/sequencer" to continue a cherry-pick that stopped because of a conflict or other error. It works by dropping the first instruction from .git/sequencer/todo and performing the remaining cherry-picks listed there, with options (think "-s" and "-X") from the initial command listed in ".git/sequencer/opts". So now you can do: $ git cherry-pick -Xpatience foo..bar ... description conflict in commit moo ... $ git cherry-pick --continue error: 'cherry-pick' is not possible because you have unmerged files. fatal: failed to resume cherry-pick $ echo resolved >conflictingfile $ git add conflictingfile && git commit $ git cherry-pick --continue; # resumes with the commit after "moo" During the "git commit" stage, CHERRY_PICK_HEAD will aid by providing the commit message from the conflicting "moo" commit. Note that the cherry-pick mechanism has no control at this stage, so the user is free to violate anything that was specified during the first cherry-pick invocation. For example, if "-x" was specified during the first cherry-pick invocation, the user is free to edit out the message during commit time. Note that the "--signoff" option specified at cherry-pick invocation time is not reflected in the commit message provided by CHERRY_PICK_HEAD; the user must take care to add "--signoff" during the "git commit" invocation. Helped-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04revert: Introduce --reset to remove sequencer stateLibravatar Ramkumar Ramachandra1-0/+5
To explicitly remove the sequencer state for a fresh cherry-pick or revert invocation, introduce a new subcommand called "--reset" to remove the sequencer state. Take the opportunity to publicly expose the sequencer paths, and a generic function called "remove_sequencer_state" that various git programs can use to remove the sequencer state in a uniform manner; "git reset" uses it later in this series. Introducing this public API is also in line with our long-term goal of eventually factoring out functions from revert.c into a generic commit sequencer. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.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-28cherry-pick/revert: add support for -X/--strategy-optionLibravatar Jonathan Nieder1-0/+10
For example, this would allow cherry-picking or reverting patches from a piece of history with a different end-of-line style, like so: $ git revert -Xrenormalize old-problematic-commit Currently that is possible with manual use of merge-recursive but the cherry-pick/revert porcelain does not expose the functionality. While at it, document the existing support for --strategy. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-02Documentation: Fix mark-up of lines with more than one tildeLibravatar Junio C Hamano1-1/+1
The manual pages of cherry-pick and revert had examples with two revisions on the same line in the examples section, that looked like this: git cherry-pick master~4 master~2:: Unfortunately, this is taken as a mark-up to make the part between two tildes, "4 master", subscript. Use {tilde} to make it explicit that we do want ~ characters in these places (backslash does not help). Reported-by: Sylvain Rabot <sylvain.rabot@f-secure.com> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-13Documentation: gitrevisions is in section 7Libravatar Jonathan Nieder1-1/+1
Fix references to gitrevisions(1) in the manual pages and HTML documentation. In practice, this will not matter much unless someone tries to use a hard copy of the git reference manual. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05Documentation: link to gitrevisions rather than git-rev-parseLibravatar Michael J Gruber1-1/+1
Currently, whenever we need documentation for revisions and ranges, we link to the git-rev-parse man page, i.e. a plumbing man page, which has this along with the documentation of all rev-parse modes. Link to the new gitrevisions man page instead in all cases except - when the actual git-rev-parse command is referred to or - in very technical context (git-send-pack). Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-02Documentation/revert: describe passing more than one commitLibravatar Christian Couder1-14/+37
And while at it, add an "EXAMPLES" section. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> 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.
2010-01-10Documentation: format full commands in typewriter fontLibravatar Thomas Rast1-2/+2
Use `code snippet` style instead of 'emphasis' for `git cmd ...` according to the following rules: * The SYNOPSIS sections are left untouched. * If the intent is that the user type the command exactly as given, it is `code`. If the user is only loosely referred to a command and/or option, it remains 'emphasised'. Signed-off-by: Thomas Rast <trast@student.ethz.ch>
2008-12-21git-revert documentation: refer to new HOWTO on reverting faulty mergesLibravatar Boyd Stephen Smith Jr1-0/+8
Signed-off-by: Boyd Stephen Smith Jr <bss@iguanasuicide.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-20Add hints to revert documentation about other ways to undo changesLibravatar Tarmigan Casebolt1-0/+9
Based on its name, people may read the 'git revert' documentation when they want to undo local changes, especially people who have used other SCM's. 'git revert' may not be what they had in mind, but git provides several other ways to undo changes to files. We can help them by pointing them towards the git commands that do what they might want to do. Cc: Daniel Barkalow <barkalow@iabervon.org> Cc: Lea Wiemann <lewiemann@gmail.com> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-21Update my e-mail addressLibravatar Junio C Hamano1-1/+1
The old cox.net address is still getting mails from gitters. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-16Merge branch 'maint'Libravatar Junio C Hamano1-8/+8
* maint: Start preparing 1.5.6.4 release notes git fetch-pack: do not complain about "no common commits" in an empty repo rebase-i: keep old parents when preserving merges t7600-merge: Use test_expect_failure to test option parsing Fix buffer overflow in prepare_attr_stack Fix buffer overflow in git diff Fix buffer overflow in git-grep git-cvsserver: fix call to nonexistant cleanupWorkDir() Documentation/git-cherry-pick.txt et al.: Fix misleading -n description Conflicts: RelNotes
2008-07-16Documentation/git-cherry-pick.txt et al.: Fix misleading -n descriptionLibravatar Petr Baudis1-8/+8
The manual page of git-cherry-pick and git-revert asserts that -n works primarily on the working tree, while in fact the primary object it operates on is the index, and the changes only "accidentally" propagate to the working tree. This e.g. leads innocent #git IRC folks to believe that you can use -n to prepare changes for git-add -i staging. Signed-off-by: Petr Baudis <pasky@suse.cz> 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: be consistent about "git-" versus "git "Libravatar Jonathan Nieder1-1/+1
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-08Docs: Use "-l::\n--long\n" format in OPTIONS sectionsLibravatar Stephan Beyer1-4/+8
The OPTIONS section of a documentation file contains a list of the options a git command accepts. Currently there are several variants to describe the case that different options (almost) do the same in the OPTIONS section. Some are: -f, --foo:: -f|--foo:: -f | --foo:: But AsciiDoc has the special form: -f:: --foo:: This patch applies this form to the documentation of the whole git suite, and removes useless em-dash prevention, so \--foo becomes --foo. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> 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-26Allow cherry-pick (and revert) to add signoff lineLibravatar Dan McGee1-1/+4
I often find myself pulling patches off of other peoples trees using cherry-pick, and following it with an immediate 'git commit --amend -s' command. Eliminate the need for a double commit by allowing signoff on a cherry-pick or revert. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-19doc typo: s/prior committing/prior to committing/Libravatar Jim Meyering1-1/+1
Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-06Documentation: rename gitlink macro to linkgitLibravatar Dan McGee1-2/+2
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-10-26revert/cherry-pick: work on merge commits as wellLibravatar Junio C Hamano1-1/+8
Usually you cannot revert a merge because you do not know which side of the merge should be considered the mainline (iow, what change to reverse). With this patch, cherry-pick and revert learn -m (--mainline) option that lets you specify the parent number (starting from 1) of the mainline, so that you can: git revert -m 1 $merge to reverse the changes introduced by the $merge commit relative to its first parent, and: git cherry-pick -m 2 $merge to replay the changes introduced by the $merge commit relative to its second parent. 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-01-17Refer users to git-rev-parse for revision specification syntax.Libravatar Shawn O. Pearce1-0/+2
The revision specification syntax (sometimes referred to as SHA1-expressions) is accepted almost everywhere in Git by almost every tool. Unfortunately it is only documented in git-rev-parse.txt, and most users don't know to look there. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-09Remove trailing dot after short descriptionLibravatar Fredrik Kuivinen1-1/+1
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-08Add documentation for git-revert and git-cherry-pick.Libravatar Nikolai Weibull1-2/+2
* Added the -e option to the documentation of git-cherry-pick. * Added the -e and --no-commit option to git-revert. * Removed redundant case expression for -n as --no-edit (already taken by --no-commit). Signed-off-by: Nikolai Weibull <nikolai@bitwi.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-04Document the --(no-)edit switch of git-revert and git-cherry-pickLibravatar Petr Baudis1-1/+10
This switch was not documented properly. I decided not to mention the --no-edit switch in the git-cherry-pick documentation since we always default to no editing. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-03[PATCH] Random documentation fixesLibravatar Jonas Fonseca1-3/+3
The fixes focuses on improving the HTML output. Most noteworthy: - Fix the Makefile to also make various *.html files depend on included files. - Consistently use 'NOTE: ...' instead of '[ ... ]' for additional info. - Fix ending '::' for description lists in OPTION section etc. - Fix paragraphs in description lists ending up as preformated text. - Always use listingblocks (preformatted text wrapped in lines with -----) for examples that span empty lines, so they are put in only one HTML block. - Use '1.' instead of '(1)' for numbered lists. - Fix linking to other GIT docs. - git-rev-list.txt: put option descriptions in an OPTION section. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-20[PATCH] Documentation: Update all files to use the new gitlink: macroLibravatar Sergey Vlasov1-1/+1
The replacement was performed automatically by these commands: perl -pi -e 's/link:(git.+)\.html\[\1\]/gitlink:$1\[1\]/g' \ README Documentation/*.txt perl -pi -e 's/link:git\.html\[git\]/gitlink:git\[7\]/g' \ README Documentation/*.txt Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-07Big tool rename.Libravatar Junio C Hamano1-0/+48
As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano <junkio@cox.net>