summaryrefslogtreecommitdiff
path: root/Documentation/git-rebase.txt
AgeCommit message (Collapse)AuthorFilesLines
2008-06-08Docs: Use "-l::\n--long\n" format in OPTIONS sectionsLibravatar Stephan Beyer1-5/+10
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-03-10update 'git rebase' documentationLibravatar SZEDER Gábor1-2/+1
Being in the project's top directory when starting or continuing a rebase is not necessary since 533b703 (Allow whole-tree operations to be started from a subdirectory, 2007-01-12). Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-01Documentation/git-rebase.txt: Add --strategy to synopsysLibravatar Mike Hommey1-0/+1
Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-06Documentation: rename gitlink macro to linkgitLibravatar Dan McGee1-5/+5
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-16git-rebase: document suppression of duplicate commitsLibravatar Jeff King1-1/+24
git-rebase uses format-patch's --ignore-if-in-upstream option, but we never document the user-visible behavior. The example is placed near the top of the example list rather than at the bottom because it is: a. a simple example b. a reasonably common scenario for many projects (mail some patches which get accepted upstream, then rebase) [sp: Corrected direction of 'HEAD..<upstream>' set comparsion] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-09-29Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: git-remote: exit with non-zero status after detecting errors. rebase -i: squash should retain the authorship of the _first_ commit git-add--interactive: Improve behavior on bogus input git-add--interactive: Allow Ctrl-D to exit
2007-09-29rebase -i: squash should retain the authorship of the _first_ commitLibravatar Johannes Schindelin1-1/+1
It was determined on the mailing list, that it makes more sense for a "squash" to keep the author of the first commit as the author for the result of the squash. Make it so. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-07git-rebase: support --whitespace=<option>Libravatar J. Bruce Fields1-2/+7
Pass --whitespace=<option> to git-apply. Since git-apply and git-am expect this, I'm always surprised when I try to give it to git-rebase and it doesn't work. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-01Mention -m as an abbreviation for --mergeLibravatar Robin Rosenberg1-2/+2
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-31rebase -i: mention the option to split commits in the man pageLibravatar Johannes Schindelin1-1/+38
The interactive mode of rebase can be used to split commits. Tell the interested parties about it, with a dedicated section in the man page. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-16Documentation/git-rebase: fix an exampleLibravatar Junio C Hamano1-1/+1
The example miscounted the commit to rebase from. Noticed by Cliff Brake. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-26Teach rebase -i about --preserve-mergesLibravatar Johannes Schindelin1-1/+22
The option "-p" (or long "--preserve-merges") makes it possible to rebase side branches including merges, without straightening the history. Example: X \ A---M---B / ---o---O---P---Q When the current HEAD is "B", "git rebase -i -p --onto Q O" will yield X \ ---o---O---P---Q---A'---M'---B' Note that this will - _not_ touch X [*1*], it does - _not_ work without the --interactive flag [*2*], it does - _not_ guess the type of the merge, but blindly uses recursive or whatever strategy you provided with "-s <strategy>" for all merges it has to redo, and it does - _not_ make use of the original merge commit via git-rerere. *1*: only commits which reach a merge base between <upstream> and HEAD are reapplied. The others are kept as-are. *2*: git-rebase without --interactive is inherently patch based (at least at the moment), and therefore merges cannot be preserved. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-24Teach rebase an interactive modeLibravatar Johannes Schindelin1-3/+82
Don't you just hate the fact sometimes, that git-rebase just applies the patches, without any possibility to edit them, or rearrange them? With "--interactive", git-rebase now lets you edit the list of patches, so that you can reorder, edit and delete patches. Such a list will typically look like this: pick deadbee The oneline of this commit pick fa1afe1 The oneline of the next commit ... By replacing the command "pick" with the command "edit", you can amend that patch and/or its commit message, and by replacing it with "squash" you can tell rebase to fold that patch into the patch before that. It is derived from the script sent to the list in <Pine.LNX.4.63.0702252156190.22628@wbgn013.biozentrum.uni-wuerzburg.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 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-05-18Documentation: Added [verse] to SYNOPSIS where necessaryLibravatar Matthias Kestenholz1-1/+1
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17Convert update-index references in docs to add.Libravatar Shawn O. Pearce1-1/+1
Since `git add` is the approved porcelain for an end-user to invoke when they want to manipulate the index, porcelain documentation should steer the user to this command rather than the pure plumbing update-index. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17Attempt to improve git-rebase lead-in description.Libravatar Shawn O. Pearce1-8/+14
It was mentioned on #git this morning that the lead-in description of git-rebase is very confusing. Too many branch this and branch that in a very short run of text. This new description attempts to walk the user through the command syntax, while also describing exactly what git-rebase is doing to their repository. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-11Documentation: git-rebase -C<n>Libravatar Junio C Hamano1-1/+1
Replace -CNUM in Synopsis section with -C<n> to make it consistent with the description text. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-08add -C[NUM] to git-amLibravatar Michael S. Tsirkin1-1/+7
Add -C[NUM] to git-am and git-rebase so that patches can be applied even if context has changed a bit. Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05Show an example of deleting commits with git-rebase.Libravatar Shawn O. Pearce1-2/+25
This particular use of git-rebase to remove a single commit or a range of commits from the history of a branch recently came up on the mailing list. Documenting the example should help other users arrive at the same solution on their own. It also was not obvious to the newcomer that git-rebase is able to accept any commit for --onto <newbase> and <upstream>. We should at least minimally document this, as much of the language in git-rebase's manpage refers to 'branch' rather than 'committish'. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-18Documentation: sync git.txt command list and manual page titleLibravatar Junio C Hamano1-1/+1
Also reorders a handful entries to make each list sorted alphabetically. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-06Merge branch 'maint'Libravatar Junio C Hamano1-8/+57
* maint: Documentation: Transplanting branch with git-rebase --onto merge-recursive implicitely depends on trust_executable_bit adjust_shared_perm: chmod() only when needed. Fix git-runstatus for repositories containing a file named HEAD
2006-11-06Documentation: Transplanting branch with git-rebase --ontoLibravatar Jakub Narebski1-8/+57
Added example of transplantig feature branch from one development branch (for example "next") into the other development branch (for example "master"). [jc: talking Carl's advice this contains both examples sent to the list by Jakub in his original message.] Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-04git-rebase: Add a -v option to show a diffstat of the changes upstream at ↵Libravatar Robert Shearman1-1/+4
the start of a rebase. Signed-off-by: Robert Shearman <rob@codeweavers.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-25rebase: allow --skip to work with --mergeLibravatar Eric Wong1-1/+0
Now that we control the merge base selection, we won't be forced into rolling things in that we wanted to skip beforehand. Also, add a test to ensure this all works as intended. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-21rebase: Allow merge strategies to be used when rebasingLibravatar Eric Wong1-1/+19
This solves the problem of rebasing local commits against an upstream that has renamed files. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-14Make git rebase interactive help match documentation.Libravatar Sean1-6/+5
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-26Add --continue and --abort options to git-rebase.Libravatar sean1-13/+63
git rebase [--onto <newbase>] <upstream> [<branch>] git rebase --continue git rebase --abort Add "--continue" to restart the rebase process after manually resolving conflicts. The user is warned if there are still differences between the index and the working files. Add "--abort" to restore the original branch, and remove the .dotest working files. Some minor additions to the git-rebase documentation. [jc: fix that applies to the maintenance track has been dealt with separately.] Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-26Document git-rebase behavior on conflicts.Libravatar J. Bruce Fields1-0/+12
2006-03-17Clarify git-rebase example commands.Libravatar Jon Loeliger1-3/+3
Signed-off-by: Jon Loeliger <jdl@jdl.com> 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>
2006-02-21git-rebase: Clarify usage statement and copy it into the actual documentation.Libravatar Carl Worth1-2/+42
I found a paper thin man page for git-rebase, but was quite happy to see something much more useful in the usage statement of the script when I went there to find out how this thing worked. Here it is cleaned up slightly and expanded a bit into the actual documentation. Signed-off-by: Carl Worth <cworth@cworth.org> 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/+35
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>