summaryrefslogtreecommitdiff
path: root/Documentation/git-rebase.txt
AgeCommit message (Collapse)AuthorFilesLines
2018-05-25Use proper syntax for replaceables in command docsLibravatar Robert P. J. Day1-2/+2
The standard for command documentation synopses appears to be: [...] means optional <...> means replaceable [<...>] means both optional and replaceable So fix a number of doc pages that use incorrect variations of the above. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26rebase -i --rebase-merges: add a section to the man pageLibravatar Johannes Schindelin1-0/+135
The --rebase-merges mode is probably not half as intuitive to use as its inventor hopes, so let's document it some. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26rebase -i: introduce --rebase-merges=[no-]rebase-cousinsLibravatar Johannes Schindelin1-4/+11
When running `git rebase --rebase-merges` non-interactively with an ancestor of HEAD as <upstream> (or leaving the todo list unmodified), we would ideally recreate the exact same commits as before the rebase. However, if there are commits in the commit range <upstream>.. that do not have <upstream> as direct ancestor (i.e. if `git log <upstream>..` would show commits that are omitted by `git log --ancestry-path <upstream>..`), this is currently not the case: we would turn them into commits that have <upstream> as direct ancestor. Let's illustrate that with a diagram: C / \ A - B - E - F \ / D Currently, after running `git rebase -i --rebase-merges B`, the new branch structure would be (pay particular attention to the commit `D`): --- C' -- / \ A - B ------ E' - F' \ / D' This is not really preserving the branch topology from before! The reason is that the commit `D` does not have `B` as ancestor, and therefore it gets rebased onto `B`. This is unintuitive behavior. Even worse, when recreating branch structure, most use cases would appear to want cousins *not* to be rebased onto the new base commit. For example, Git for Windows (the heaviest user of the Git garden shears, which served as the blueprint for --rebase-merges) frequently merges branches from `next` early, and these branches certainly do *not* want to be rebased. In the example above, the desired outcome would look like this: --- C' -- / \ A - B ------ E' - F' \ / -- D' -- Let's introduce the term "cousins" for such commits ("D" in the example), and let's not rebase them by default. For hypothetical use cases where cousins *do* need to be rebased, `git rebase --rebase=merges=rebase-cousins` needs to be used. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26rebase: introduce the --rebase-merges optionLibravatar Johannes Schindelin1-1/+20
Once upon a time, this here developer thought: wouldn't it be nice if, say, Git for Windows' patches on top of core Git could be represented as a thicket of branches, and be rebased on top of core Git in order to maintain a cherry-pick'able set of patch series? The original attempt to answer this was: git rebase --preserve-merges. However, that experiment was never intended as an interactive option, and it only piggy-backed on git rebase --interactive because that command's implementation looked already very, very familiar: it was designed by the same person who designed --preserve-merges: yours truly. Some time later, some other developer (I am looking at you, Andreas! ;-)) decided that it would be a good idea to allow --preserve-merges to be combined with --interactive (with caveats!) and the Git maintainer (well, the interim Git maintainer during Junio's absence, that is) agreed, and that is when the glamor of the --preserve-merges design started to fall apart rather quickly and unglamorously. The reason? In --preserve-merges mode, the parents of a merge commit (or for that matter, of *any* commit) were not stated explicitly, but were *implied* by the commit name passed to the `pick` command. This made it impossible, for example, to reorder commits. Not to mention to move commits between branches or, deity forbid, to split topic branches into two. Alas, these shortcomings also prevented that mode (whose original purpose was to serve Git for Windows' needs, with the additional hope that it may be useful to others, too) from serving Git for Windows' needs. Five years later, when it became really untenable to have one unwieldy, big hodge-podge patch series of partly related, partly unrelated patches in Git for Windows that was rebased onto core Git's tags from time to time (earning the undeserved wrath of the developer of the ill-fated git-remote-hg series that first obsoleted Git for Windows' competing approach, only to be abandoned without maintainer later) was really untenable, the "Git garden shears" were born [*1*/*2*]: a script, piggy-backing on top of the interactive rebase, that would first determine the branch topology of the patches to be rebased, create a pseudo todo list for further editing, transform the result into a real todo list (making heavy use of the `exec` command to "implement" the missing todo list commands) and finally recreate the patch series on top of the new base commit. That was in 2013. And it took about three weeks to come up with the design and implement it as an out-of-tree script. Needless to say, the implementation needed quite a few years to stabilize, all the while the design itself proved itself sound. With this patch, the goodness of the Git garden shears comes to `git rebase -i` itself. Passing the `--rebase-merges` option will generate a todo list that can be understood readily, and where it is obvious how to reorder commits. New branches can be introduced by inserting `label` commands and calling `merge <label>`. And once this mode will have become stable and universally accepted, we can deprecate the design mistake that was `--preserve-merges`. Link *1*: https://github.com/msysgit/msysgit/blob/master/share/msysGit/shears.sh Link *2*: https://github.com/git-for-windows/build-extra/blob/master/shears.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25Merge branch 'pw/rebase-signoff'Libravatar Junio C Hamano1-3/+4
"git rebase" has learned to honor "--signoff" option when using backends other than "am" (but not "--preserve-merges"). * pw/rebase-signoff: rebase --keep-empty: always use interactive rebase rebase -p: error out if --signoff is given rebase: extend --signoff support
2018-03-29rebase: extend --signoff supportLibravatar Phillip Wood1-3/+4
Allow --signoff to be used with --interactive and --merge. In interactive mode only commits marked to be picked, edited or reworded will be signed off. The main motivation for this patch was to allow one to run 'git rebase --exec "make check" --signoff' which is useful when preparing a patch series for publication and is more convenient than doing the signoff with another --exec command. This change also allows --root without --onto to work with --signoff as well (--root with --onto was already supported). Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-06Merge branch 'nd/rebase-show-current-patch'Libravatar Junio C Hamano1-1/+6
The new "--show-current-patch" option gives an end-user facing way to get the diff being applied when "git rebase" (and "git am") stops with a conflict. * nd/rebase-show-current-patch: rebase: introduce and use pseudo-ref REBASE_HEAD rebase: add --show-current-patch am: add --show-current-patch
2018-02-12rebase: introduce and use pseudo-ref REBASE_HEADLibravatar Nguyễn Thái Ngọc Duy1-1/+2
The new command `git rebase --show-current-patch` is useful for seeing the commit related to the current rebase state. Some however may find the "git show" command behind it too limiting. You may want to increase context lines, do a diff that ignores whitespaces... For these advanced use cases, the user can execute any command they want with the new pseudo ref REBASE_HEAD. This also helps show where the stopped commit is from, which is hard to see from the previous patch which implements --show-current-patch. Helped-by: Tim Landscheidt <tim@tim-landscheidt.de> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-12rebase: add --show-current-patchLibravatar Nguyễn Thái Ngọc Duy1-1/+5
It is useful to see the full patch while resolving conflicts in a rebase. The only way to do it now is less .git/rebase-*/patch which could turn out to be a lot longer to type if you are in a linked worktree, or not at top-dir. On top of that, an ordinary user should not need to peek into .git directory. The new option is provided to examine the patch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-07rebase: add --allow-empty-message optionLibravatar Genki Sky1-0/+5
This option allows commits with empty commit messages to be rebased, matching the same option in git-commit and git-cherry-pick. While empty log messages are frowned upon, sometimes one finds them in older repositories (e.g. translated from another VCS [0]), or have other reasons for desiring them. The option is available in git-commit and git-cherry-pick, so it is natural to make other git tools play nicely with them. Adding this as an option allows the default to be "give the user a chance to fix", while not interrupting the user's workflow otherwise [1]. [0]: https://stackoverflow.com/q/8542304 [1]: https://public-inbox.org/git/7vd33afqjh.fsf@alter.siamese.dyndns.org/ To implement this, add a new --allow-empty-message flag. Then propagate it to all calls of 'git commit', 'git cherry-pick', and 'git rebase--helper' within the rebase scripts. Signed-off-by: Genki Sky <sky@genki.is> Reviewed-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-04Documentation: move rebase.* configs to new fileLibravatar Liam Beguin1-18/+1
Move all rebase.* configuration variables to a separate file in order to remove duplicates, and include it in config.txt and git-rebase.txt. The new descriptions are mostly taken from config.txt as they are more verbose. Signed-off-by: Liam Beguin <liambeguin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-03Merge branch 'js/rebase-i-final'Libravatar Junio C Hamano1-7/+9
The final batch to "git rebase -i" updates to move more code from the shell script to C. * js/rebase-i-final: rebase -i: rearrange fixup/squash lines using the rebase--helper t3415: test fixup with wrapped oneline rebase -i: skip unnecessary picks using the rebase--helper rebase -i: check for missing commits in the rebase--helper t3404: relax rebase.missingCommitsCheck tests rebase -i: also expand/collapse the SHA-1s via the rebase--helper rebase -i: do not invent onelines when expanding/collapsing SHA-1s rebase -i: remove useless indentation rebase -i: generate the script via rebase--helper t3415: verify that an empty instructionFormat is handled as before
2017-08-23treewide: correct several "up-to-date" to "up to date"Libravatar Martin Ågren1-1/+1
Follow the Oxford style, which says to use "up-to-date" before the noun, but "up to date" after it. Don't change plumbing (specifically send-pack.c, but transport.c (git push) also has the same string). This was produced by grepping for "up-to-date" and "up to date". It turned out we only had to edit in one direction, removing the hyphens. Fix a typo in Documentation/git-diff-index.txt while we're there. Reported-by: Jeffrey Manian <jeffrey.manian@gmail.com> Reported-by: STEVEN WHITE <stevencharleswhitevoices@gmail.com> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-27rebase -i: rearrange fixup/squash lines using the rebase--helperLibravatar Johannes Schindelin1-7/+9
This operation has quadratic complexity, which is especially painful on Windows, where shell scripts are *already* slow (mainly due to the overhead of the POSIX emulation layer). Let's reimplement this with linear complexity (using a hash map to match the commits' subject lines) for the common case; Sadly, the fixup/squash feature's design neglected performance considerations, allowing arbitrary prefixes (read: `fixup! hell` will match the commit subject `hello world`), which means that we are stuck with quadratic performance in the worst case. The reimplemented logic also happens to fix a bug where commented-out lines (representing empty patches) were dropped by the previous code. While at it, clarify how the fixup/squash feature works in `git rebase -i`'s man page. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-12Merge branch 'ks/fix-rebase-doc-picture'Libravatar Junio C Hamano1-1/+1
Doc update. * ks/fix-rebase-doc-picture: doc: correct a mistake in an illustration
2017-07-10doc: correct a mistake in an illustrationLibravatar Kaartic Sivaraam1-1/+1
The first illustration of the "RECOVERING FROM UPSTREAM REBASE" section in the 'git-rebase' documentation meant to depict that there are number of commits on the 'master' branch, but it is longer than the 'master' branch in the following illustrations by one commit, even though there is no resetting of 'master' to lose that commit. Correct it. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18stash: update documentation to use 'stash entry'Libravatar Liam Beguin1-1/+1
Most of the time, a 'stash entry' is called a 'stash'. Lets try to make this more consistent and use 'stash entry' instead. Signed-off-by: Liam Beguin <liambeguin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-26Merge branch 'gb/rebase-signoff'Libravatar Junio C Hamano1-0/+5
"git rebase" learns "--signoff" option. * gb/rebase-signoff: rebase: pass --[no-]signoff option to git am builtin/am: fold am_signoff() into am_append_signoff() builtin/am: honor --signoff also when --rebasing
2017-04-18rebase: pass --[no-]signoff option to git amLibravatar Giuseppe Bilotta1-0/+5
This makes it easy to sign off a whole patchset before submission. Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-19Merge branch 'nd/rebase-forget'Libravatar Junio C Hamano1-1/+6
"git rebase" learned "--quit" option, which allows a user to remove the metadata left by an earlier "git rebase" that was manually aborted without using "git rebase --abort". * nd/rebase-forget: rebase: add --quit to cleanup rebase, leave everything else untouched
2016-12-11rebase: add --quit to cleanup rebase, leave everything else untouchedLibravatar Nguyễn Thái Ngọc Duy1-1/+6
There are occasions when you decide to abort an in-progress rebase and move on to do something else but you forget to do "git rebase --abort" first. Or the rebase has been in progress for so long you forgot about it. By the time you realize that (e.g. by starting another rebase) it's already too late to retrace your steps. The solution is normally rm -r .git/<some rebase dir> and continue with your life. But there could be two different directories for <some rebase dir> (and it obviously requires some knowledge of how rebase works), and the ".git" part could be much longer if you are not at top-dir, or in a linked worktree. And "rm -r" is very dangerous to do in .git, a mistake in there could destroy object database or other important data. Provide "git rebase --quit" for this use case, mimicking a precedent that is "git cherry-pick --quit". Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-28Merge branch 'mm/doc-tt' into maintLibravatar Junio C Hamano1-5/+5
More mark-up updates to typeset strings that are expected to literally typed by the end user in fixed-width font. * mm/doc-tt: doc: typeset HEAD and variants as literal CodingGuidelines: formatting HEAD in documentation doc: typeset long options with argument as literal doc: typeset '--' as literal doc: typeset long command-line options as literal doc: typeset short command-line options as literal Documentation/git-mv.txt: fix whitespace indentation
2016-07-13Merge branch 'mm/doc-tt'Libravatar Junio C Hamano1-5/+5
More mark-up updates to typeset strings that are expected to literally typed by the end user in fixed-width font. * mm/doc-tt: doc: typeset HEAD and variants as literal CodingGuidelines: formatting HEAD in documentation doc: typeset long options with argument as literal doc: typeset '--' as literal doc: typeset long command-line options as literal doc: typeset short command-line options as literal Documentation/git-mv.txt: fix whitespace indentation
2016-06-28doc: typeset long command-line options as literalLibravatar Matthieu Moy1-5/+5
Similarly to the previous commit, use backquotes instead of forward-quotes, for long options. This was obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt and manual tweak to remove false positive in ascii-art (o'--o'--o' to describe rewritten history). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-18rebase: decouple --exec from --interactiveLibravatar Stefan Beller1-3/+3
In the later steps of preparing a patch series I do not want to edit or reorder the patches any more, but just make sure the test suite passes after each patch and also to fix breakage right there if some of the steps fail. I could run EDITOR=true git rebase -i <anchor> -x "make test" but it would be simpler if it can be spelled like so: git rebase <anchor> -x "make test" Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-02Documentation: reword rebase summaryLibravatar Stefan Beller1-1/+1
The wording is introduced in c3f0baaca (Documentation: sync git.txt command list and manual page title, 2007-01-18), but rebase has evolved since then, capture the modern usage by being more generic about the rebase command in the summary. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-05Merge branch 'mm/keyid-docs'Libravatar Junio C Hamano1-1/+3
Very small number of options take a parameter that is optional (which is not a great UI element as they can only appear at the end of the command line). Add notice to documentation of each and every one of them. * mm/keyid-docs: Documentation: explain optional arguments better Documentation/grep: fix documentation of -O Documentation: use 'keyid' consistently, not 'key-id'
2015-10-05Merge branch 'jk/rebase-no-autostash'Libravatar Junio C Hamano1-1/+2
There was no way to defeat a configured rebase.autostash variable from the command line, as "git rebase --no-autostash" was missing. * jk/rebase-no-autostash: Documentation/git-rebase: fix --no-autostash formatting rebase: support --no-autostash
2015-09-21Documentation: explain optional arguments betterLibravatar Matthieu Moy1-1/+3
Improve the documentation of commands taking optional arguments in two ways: * Documents the behavior of '-O' (for grep) and '-S' (for commands creating commits) when used without the optional argument. * Document the syntax of these options. For the second point, the behavior is documented in gitcli(7), but it is easy for users to miss, and hard for the same user to understand why e.g. "git status -u no" does not work. Document this explicitly in the documentation of each short option having an optional argument: they are the most error prone since there is no '=' sign between the option and its argument. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-10Documentation/git-rebase: fix --no-autostash formattingLibravatar John Keeping1-1/+2
All of the other "--option" and "--no-option" pairs in this file are formatted as separate options. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'gr/rebase-i-drop-warn'Libravatar Junio C Hamano1-0/+9
Add "drop commit-object-name subject" command as another way to skip replaying of a commit in "rebase -i", and then punish those who do not use it (and instead just remove the lines) by throwing a warning. * gr/rebase-i-drop-warn: git rebase -i: add static check for commands and SHA-1 git rebase -i: warn about removed commits git-rebase -i: add command "drop" to remove a commit
2015-06-30git rebase -i: warn about removed commitsLibravatar Galan Rémi1-0/+6
Check if commits were removed (i.e. a line was deleted) and print warnings or stop git rebase depending on the value of the configuration variable rebase.missingCommitsCheck. This patch gives the user the possibility to avoid silent loss of information (losing a commit through deleting the line in this case) if he wants. Add the configuration variable rebase.missingCommitsCheck. - When unset or set to "ignore", no checking is done. - When set to "warn", the commits are checked, warnings are displayed but git rebase still proceeds. - When set to "error", the commits are checked, warnings are displayed and the rebase is stopped. (The user can then use 'git rebase --edit-todo' and 'git rebase --continue', or 'git rebase --abort') rebase.missingCommitsCheck defaults to "ignore". Signed-off-by: Galan Rémi <remi.galan-alfonso@ensimag.grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-30git-rebase -i: add command "drop" to remove a commitLibravatar Galan Rémi1-0/+3
Instead of removing a line to remove the commit, you can use the command "drop" (just like "pick" or "edit"). It has the same effect as deleting the line (removing the commit) except that you keep a visual trace of your actions, allowing a better control and reducing the possibility of removing a commit by mistake. Signed-off-by: Galan Rémi <remi.galan-alfonso@ensimag.grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-15git-rebase--interactive.sh: add config option for custom instruction formatLibravatar Michael Rappazzo1-0/+7
A config option 'rebase.instructionFormat' can override the default 'oneline' format of the rebase instruction list. Since the list is parsed using the left, right or boundary mark plus the sha1, they are prepended to the instruction format. Signed-off-by: Michael Rappazzo <rappazzo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22Merge branch 'jk/asciidoc-markup-fix'Libravatar Junio C Hamano1-1/+1
Various documentation mark-up fixes to make the output more consistent in general and also make AsciiDoctor (an alternative formatter) happier. * jk/asciidoc-markup-fix: doc: convert AsciiDoc {?foo} to ifdef::foo[] doc: put example URLs and emails inside literal backticks doc: drop backslash quoting of some curly braces doc: convert \--option to --option doc/add: reformat `--edit` option doc: fix length of underlined section-title doc: fix hanging "+"-continuation doc: fix unquoted use of "{type}" doc: fix misrendering due to `single quote'
2015-05-12doc: fix misrendering due to `single quote'Libravatar Jeff King1-1/+1
AsciiDoc misparses some text that contains a `literal` word followed by a fancy `single quote' word, and treats everything from the start of the literal to the end of the quote as a single-quoted phrase. We can work around this by switching the latter to be a literal, as well. In the first case, this is perhaps what was intended anyway, as it makes us consistent with the the earlier literals in the same paragraph. In the second, the output is arguably better, as we will format our commit references as <code> blocks. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>