summaryrefslogtreecommitdiff
path: root/Documentation/git-rebase.txt
AgeCommit message (Collapse)AuthorFilesLines
2015-03-31Sync with 2.3.5Libravatar Junio C Hamano1-1/+3
* maint: Git 2.3.5 docs: clarify what git-rebase's "-p" / "--preserve-merges" does
2015-03-31Merge branch 'ss/pull-rebase-preserve' into maintLibravatar Junio C Hamano1-1/+3
* ss/pull-rebase-preserve: docs: clarify what git-rebase's "-p" / "--preserve-merges" does docs: clarify "preserve" option wording for git-pull
2015-03-30docs: clarify what git-rebase's "-p" / "--preserve-merges" doesLibravatar Sebastian Schuberth1-1/+3
Ignoring a merge can be read as ignoring the changes a merge commit introduces altogether, as if the entire side branch the merge commit merged was removed from the history. But that is not what happens if "-p" is not specified. What happens is that the individual commits a merge commit introduces are replayed in order, and only any possible merge conflict resolutions or manual amendments to the merge commit are ignored. Get this straight in the docs. Also, do not say that merge commits are *tried* to be recreated. As that is true almost everywhere it is better left unsaid. Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-13*config.txt: stick to camelCase naming conventionLibravatar Nguyễn Thái Ngọc Duy1-3/+3
This should improve readability. Compare "thislongname" and "thisLongName". The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-14Merge branch 'so/rebase-doc-fork-point'Libravatar Junio C Hamano1-12/+19
* so/rebase-doc-fork-point: Documentation/git-rebase.txt: document when --fork-point is auto-enabled
2014-09-29Documentation/git-rebase.txt: document when --fork-point is auto-enabledLibravatar Sergey Organov1-12/+19
Running "git rebase" without giving a specific commit with respect to which the operation is done enables --fork-point mode, while telling the command to rebase with respect to a specific commit, i.e. "git rebase <upstream>" does not. This was not mentioned in the DESCRIPTION section of the manual page, even though the case of omitted <upstream> was otherwise discussed. That in turn made actual behavior of vanilla "git rebase" hardly discoverable. While we are at it, clarify the --fork-point description itself as well. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-16Documentation/git-rebase.txt: <upstream> must be given to specify <branch>Libravatar Sergey Organov1-1/+1
Current syntax description makes one wonder if there is any syntactic way to distinguish between <branch> and <upstream> so that one can specify <branch> but not <upstream>, but that is not the case. Make it explicit that these arguments are positional, i.e. the earlier ones cannot be omitted if you want to give later ones. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-12Documentation/git-rebase.txt: -f forces a rebase that would otherwise be a no-opLibravatar Sergey Organov1-5/+2
"Current branch is a descendant of the commit you are rebasing onto" does not necessarily mean "rebase" requires "--force". For a plain vanilla "history flattening" rebase, the rebase can be done without forcing if there is a merge between the tip of the branch being rebased and the commit you are rebasing onto, even if the tip is descendant of the other. [jc: reworded both the text and the log description] Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-11rebase: add the --gpg-sign optionLibravatar Nicolas Vigier1-0/+4
Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10rebase: use reflog to find common base with upstreamLibravatar John Keeping1-0/+10
Commit 15a147e (rebase: use @{upstream} if no upstream specified, 2011-02-09) says: Make it default to 'git rebase @{upstream}'. That is also what 'git pull [--rebase]' defaults to, so it only makes sense that 'git rebase' defaults to the same thing. but that isn't actually the case. Since commit d44e712 (pull: support rebased upstream + fetch + pull --rebase, 2009-07-19), pull has actually chosen the most recent reflog entry which is an ancestor of the current branch if it can find one. Add a '--fork-point' argument to git-rebase that can be used to trigger this behaviour. This option is turned on by default if no non-option arguments are specified on the command line, otherwise we treat an upstream specified on the command-line literally. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-06Documentation: make AsciiDoc links always point to HTML filesLibravatar Sebastian Schuberth1-2/+2
AsciiDoc's "link" is supposed to create hyperlinks for HTML output, so prefer a "link" to point to an HTML file instead of a text file if an HTML version of the file is being generated. For RelNotes, keep pointing to text files as no equivalent HTML files are generated. If appropriate, also update the link description to not contain the linked file's extension. Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-27rebase -i: handle fixup! fixup! in --autosquashLibravatar Andrew Pimlott1-1/+3
In rebase -i --autosquash, ignore all "fixup! " or "squash! " after the first. This supports the case when a git commit --fixup/--squash referred to an earlier fixup/squash instead of the original commit (whether intentionally, as when the user expressly meant to note that the commit fixes an earlier fixup; or inadvertently, as when the user meant to refer to the original commit with :/msg; or out of laziness, as when the user could remember how to refer to the fixup but not the original). In the todo list, the full commit message is preserved, in case it provides useful cues to the user. A test helper set_cat_todo_editor is introduced to check this. Helped-by: Thomas Rast <trast@inf.ethz.ch> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Andrew Pimlott <andrew@pimlott.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29rebase: implement --[no-]autostash and rebase.autostashLibravatar Ramkumar Ramachandra1-0/+10
This new feature allows a rebase to be executed on a dirty worktree or index. It works by creating a temporary "dangling merge commit" out of the worktree and index changes (via 'git stash create'), and automatically applying it after a successful rebase or abort. rebase stores the SHA-1 hex of the temporary merge commit, along with the rest of the rebase state, in either .git/{rebase-merge,rebase-apply}/autostash depending on the kind of rebase. Since $state_dir is automatically removed at the end of a successful rebase or abort, so is the autostash. The advantage of this approach is that we do not affect the normal stash's reflogs, making the autostash invisible to the end-user. This means that you can use 'git stash' during a rebase as usual. When the autostash application results in a conflict, we push $state_dir/autostash onto the normal stash and remove $state_dir ending the rebase. The user can inspect the stash, and pop or drop at any time. Most significantly, this feature means that a caller like pull (with pull.rebase set to true) can easily be patched to remove the require_clean_work_tree restriction. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-1/+1
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17rebase -i: Teach "--edit-todo" actionLibravatar Andrew Wong1-1/+4
This allows users to edit the todo file while they're stopped in the middle of an interactive rebase. When this action is executed, all comments from the original todo file are stripped, and new help messages are appended to the end. Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-23Merge branch 'sn/doc-typofix'Libravatar Junio C Hamano1-1/+1
* sn/doc-typofix: doc: A few minor copy edits.
2012-07-15Merge branch 'cw/rebase-i-root'Libravatar Junio C Hamano1-4/+5
"git rebase [-i] --root $tip" can now be used to rewrite all the history down to the root. * cw/rebase-i-root: t3404: make test 57 work with dash and others Add tests for rebase -i --root without --onto rebase -i: support --root without --onto
2012-07-14doc: A few minor copy edits.Libravatar Štěpán Němec1-1/+1
- (glossary) the quotes around the Wikipedia URL prevented its linkification in frontends that support it; remove them - (manual) newer version (SHA-1) == following, older == preceding, not the other way around - trivial typo and wording fixes Signed-off-by: Štěpán Němec <stepnem@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-26rebase -i: support --root without --ontoLibravatar Chris Webb1-4/+5
Allow --root to be specified to rebase -i without --onto, making it possible to edit and re-order all commits right back to the root(s). If there is a conflict to be resolved when applying the first change, the user will expect a sane index and working tree to get sensible behaviour from git-diff and friends, so create a sentinel commit with an empty tree to rebase onto. Automatically squash the sentinel with any commits rebased directly onto it, so they end up as root commits in their own right and retain their authorship and commit message. Implicitly use rebase -i for non-interactive rebase of --root without an --onto argument now that rebase -i can correctly do this. Signed-off-by: Chris Webb <chris@arachsys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-13rebase -i: teach "--exec <cmd>"Libravatar Lucien Kong1-3/+42
During an interactive rebase session, it is sometimes desirable to run tests on each commit in the resulting history. This can be done by adding "exec <test command>" when editing the insn sheet, but the command used for testing is often the same for all resulting commits. By passing "--exec <cmd>" from the command line, automatically add these "exec" lines after each commit in the final history. To work well with the --autosquash option, these are added at the end of each run of "fixup" and "squash". Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-02Merge branch 'jk/doc-asciidoc-inline-literal'Libravatar Junio C Hamano1-5/+5
Our documentation was written for an ancient version of AsciiDoc, making the source not very readable. By Jeff King * jk/doc-asciidoc-inline-literal: docs: stop using asciidoc no-inline-literal
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-5/+5
In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24git-rebase: add keep_empty flagLibravatar Neil Horman1-0/+4
Add a command line switch to git-rebase to allow a user the ability to specify that they want to keep any commits in a series that are empty. When git-rebase's type is am, then this option will automatically keep any commit that has a tree object identical to its parent. This patch changes the default behavior of interactive rebases as well. With this patch, git-rebase -i will produce a revision set passed to git-revision-editor, in which empty commits are commented out. Empty commits may be kept manually by uncommenting them. If the new --keep-empty option is used in an interactive rebase the empty commits will automatically all be uncommented in the editor. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-26documentation: fix alphabetic ordered list for git-rebase man pageLibravatar Nelson Benitez Leon1-2/+5
An alphabetic ordered list (a.) is converted to numerical in the man page (1.) so context comments naming 'a' were confusing, fix that by not using ordered list notation for 'a' anb 'b' items. Signed-off-by: Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-22Merge branch 'mz/doc-rebase-abort'Libravatar Junio C Hamano1-2/+6
* mz/doc-rebase-abort: rebase: clarify "restore the original branch"
2011-07-13rebase: clarify "restore the original branch"Libravatar Martin von Zweigbergk1-2/+6
The description for 'git rebase --abort' currently says: Restore the original branch and abort the rebase operation. The "restore" can be misinterpreted to imply that the original branch was somehow in a broken state during the rebase operation. It is also not completely clear what "the original branch" is --- is it the branch that was checked out before the rebase operation was called or is the the branch that is being rebased (it is the latter)? Although both issues are made clear in the DESCRIPTION section, let us also make the entry in the OPTIONS secion more clear. Also remove the term "rebasing process" from the usage text, since the user already knows that the text is about "git rebase". Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-06Documentation: use [verse] for SYNOPSIS sectionsLibravatar Martin von Zweigbergk1-1/+0
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-04-28Merge branch 'mz/rebase'Libravatar Junio C Hamano1-2/+9
* mz/rebase: (34 commits) rebase: define options in OPTIONS_SPEC Makefile: do not install sourced rebase scripts rebase: use @{upstream} if no upstream specified rebase -i: remove unnecessary state rebase-root rebase -i: don't read unused variable preserve_merges git-rebase--am: remove unnecessary --3way option rebase -m: don't print exit code 2 when merge fails rebase -m: remember allow_rerere_autoupdate option rebase: remember strategy and strategy options rebase: remember verbose option rebase: extract code for writing basic state rebase: factor out sub command handling rebase: make -v a tiny bit more verbose rebase -i: align variable names rebase: show consistent conflict resolution hint rebase: extract am code to new source file rebase: extract merge code to new source file rebase: remove $branch as synonym for $orig_head rebase -i: support --stat rebase: factor out call to pre-rebase hook ...
2011-03-15Merge branch 'jk/doc-credits' of git://github.com/peff/gitLibravatar Junio C Hamano1-10/+0
* 'jk/doc-credits' of git://github.com/peff/git: docs: point git.txt author credits to git-scm.com doc: add missing git footers doc: drop author/documentation sections from most pages
2011-03-14Documentation: "rebase <onto> <that>" stays on <that> branch upon exitLibravatar Drew Northup1-2/+3
This change makes it clearer that the change to the history effected by executing 'git rebase master' while on 'topic' branch, and by executing 'git rebase master topic' on any branch, will be the same; the implicit checkout of the second form will remain after the rebase exits. Signed-off-by: Drew Northup <drew.northup@maine.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-10/+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.
2011-02-10rebase: use @{upstream} if no upstream specifiedLibravatar Martin von Zweigbergk1-2/+9
'git rebase' without arguments is currently not supported. Make it default to 'git rebase @{upstream}'. That is also what 'git pull [--rebase]' defaults to, so it only makes sense that 'git rebase' defaults to the same thing. Defaulting to @{upstream} will make it possible to run e.g. 'git rebase -i' without arguments, which is probably a quite common use case. It also improves the scenario where you have multiple branches that rebase against a remote-tracking branch, where you currently have to choose between the extra network delay of 'git pull' or the slightly awkward keys to enter 'git rebase @{u}'. The error reporting when no upstream is configured for the current branch or when no branch is checked out is reused from git-pull.sh. A function is extracted into git-parse-remote.sh for this purpose. Helped-by: Yann Dirson <ydirson@altern.org> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-23rebase: support --verifyLibravatar Martin von Zweigbergk1-0/+4
Interactive rebase allows the '--verify' option to be passed, but it will be ignored. Implement proper support for the option for both interactive and non-interactive rebase by making it override any previous '--no-verify'. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-03Merge branch 'jn/doc-backslash'Libravatar Junio C Hamano1-1/+1
* jn/doc-backslash: Documentation: remove stray backslash in show-branch discussion Documentation: remove stray backslashes from "Fighting regressions" article Documentation: do not convert ... operator to ellipses Documentation: avoid stray backslash in user manual Documentation: avoid stray backslashes in core tutorial Documentation: remove stray backslashes in rev-parse manual Documentation: remove backslash before ~ in fast-import manual Documentation: remove stray backslash from "git bundle" manual Documentation/technical: avoid stray backslash in parse-options API docs Documentation: remove backslashes in manpage synopses Documentation: clarify quoting in gitignore docs Documentation: clarify quoting in "git rm" example Documentation: add missing quotes to "git grep" examples Documentation: clarify quoting in "git add" example Documentation: unbreak regex in show-ref manual Documentation: quoting trouble in "git rm" discussion Documentation: tweak description of log.date
2010-08-31Merge branch 'hv/autosquash-config'Libravatar Junio C Hamano1-0/+8
* hv/autosquash-config: add configuration variable for --autosquash option of interactive rebase
2010-08-21Merge branch 'mm/rebase-i-exec'Libravatar Junio C Hamano1-0/+24
* mm/rebase-i-exec: git-rebase--interactive.sh: use printf instead of echo to print commit message git-rebase--interactive.sh: rework skip_unnecessary_picks test-lib: user-friendly alternatives to test [-d|-f|-e] rebase -i: add exec command to launch a shell command Conflicts: git-rebase--interactive.sh t/t3404-rebase-interactive.sh
2010-08-20Documentation: do not convert ... operator to ellipsesLibravatar Jonathan Nieder1-1/+1
The symmetric difference or merge-base operator ... as used by rev-list and diff is actually three period characters. If it gets replaced by an ellipsis glyph in the manual, that would stop readers from copying and pasting it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-11rebase -i: add exec command to launch a shell commandLibravatar Matthieu Moy1-0/+24
The typical usage pattern would be to run a test (or simply a compilation command) at given points in history. The shell command is ran (from the worktree root), and the rebase is stopped when the command fails, to give the user an opportunity to fix the problem before continuing with "git rebase --continue". This needs a little rework of skip_unnecessary_picks, which wasn't robust enough to deal with lines like exec >"file name with many spaces" in the todolist. The new version extracts command, sha1 and rest from each line, but outputs the line itself verbatim to avoid changing the whitespace layout. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-03rebase: support -X to pass through strategy optionsLibravatar Mike Lundy1-0/+7
git-rebase calls out to merge strategies, but did not support merge strategy options so far. Add this, in the same style used in git-merge. Sadly we have to do the full quoting/eval dance here, since merge-recursive supports the --subtree=<path> option which potentially contains whitespace. This patch does not cover git rebase -i, which does not call any merge strategy directly except in --preserve-merges, and even then only for merges. [jc: with a trivial fix-up for 'expr'] Signed-off-by: Mike Lundy <mike@fluffypenguin.org> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-14add configuration variable for --autosquash option of interactive rebaseLibravatar Heiko Voigt1-0/+8
If you use this feature regularly you can now enable it by default. In case the user wants to override this config on the commandline --no-autosquash can be used to force disabling. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-11rebase -i -p: document shortcomingsLibravatar Jonathan Nieder1-0/+27
The rebase --preserve-merges facility presents a list of commits in its instruction sheet and uses a separate table to keep track of their parents. Unfortunately, in practice this means that with -p after most attempts to rearrange patches, some commits have the "wrong" parent and the resulting history is rarely what the caller expected. Yes, it would be nice to fix that. But first, add a warning to the manual to help the uninitiated understand what is going on. Reported-by: Jiří Paleček <jpalecek@web.de> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-02Documentation: A...B shortcut for checkout and rebaseLibravatar Michael J Gruber1-0/+4
Describe the A...B shortcuts for checkout and rebase [-i] which were introduced in these commits: 619a64e ("checkout A...B" switches to the merge base between A and B, 2009-10-18) 61dfa1b ("rebase --onto A...B" replays history on the merge base between A and B, 2009-11-20) 230a456 (rebase -i: teach --onto A...B syntax, 2010-01-07) Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-18Documentation: rebase -i ignores options passed to "git am"Libravatar Markus Heidelberg1-0/+1
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-24Teach rebase the --no-ff option.Libravatar Marc Branchaud1-2/+21
For git-rebase.sh, --no-ff is a synonym for --force-rebase. For git-rebase--interactive.sh, --no-ff cherry-picks all the commits in the rebased branch, instead of fast-forwarding over any unchanged commits. --no-ff offers an alternative way to deal with reverted merges. Instead of "reverting the revert" you can use "rebase --no-ff" to recreate the branch with entirely new commits (they're new because at the very least the committer time is different). This obviates the need to revert the reversion, as you can re-merge the new topic branch directly. Added an addendum to revert-a-faulty-merge.txt describing the situation and how to use --no-ff to handle it. Signed-off-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-21git-rebase.txt: Fix spellingLibravatar Horst H. von Brand1-1/+1
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge remote branch 'remotes/trast-doc/for-next'Libravatar Junio C Hamano1-19/+19
* 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-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-19/+19
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-06rebase -i --autosquash: auto-squash commitsLibravatar Nanako Shiraishi1-0/+10
Teach a new option, --autosquash, to the interactive rebase. When the commit log message begins with "!fixup ...", and there is a commit whose title begins with the same ..., automatically modify the todo list of rebase -i so that the commit marked for squashing come right after the commit to be modified, and change the action of the moved commit from pick to squash. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-07Add a command "fixup" to rebase --interactiveLibravatar Michael Haggerty1-5/+8
The command is like "squash", except that it discards the commit message of the corresponding commit. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-22Merge branch 'tr/maint-merge-ours-clarification' (early part)Libravatar Junio C Hamano1-3/+13
* 'tr/maint-merge-ours-clarification' (early part): rebase docs: clarify --merge and --strategy Documentation: clarify 'ours' merge strategy