summaryrefslogtreecommitdiff
path: root/Documentation/git-rebase.txt
AgeCommit message (Collapse)AuthorFilesLines
2018-07-24Merge branch 'en/rebase-consistency'Libravatar Junio C Hamano1-27/+108
"git rebase" behaved slightly differently depending on which one of the three backends gets used; this has been documented and an effort to make them more uniform has begun. * en/rebase-consistency: git-rebase: make --allow-empty-message the default t3401: add directory rename testcases for rebase and am git-rebase.txt: document behavioral differences between modes directory-rename-detection.txt: technical docs on abilities and limitations git-rebase.txt: address confusion between --no-ff vs --force-rebase git-rebase: error out when incompatible options passed t3422: new testcases for checking when incompatible options passed git-rebase.sh: update help messages a bit git-rebase.txt: document incompatible options
2018-07-18Merge branch 'js/rebase-recreate-merge'Libravatar Junio C Hamano1-1/+1
Docfix. * js/rebase-recreate-merge: rebase: fix documentation formatting
2018-06-27git-rebase: make --allow-empty-message the defaultLibravatar Elijah Newren1-10/+0
rebase backends currently behave differently with empty commit messages, largely as a side-effect of the different underlying commands on which they are based. am-based rebases apply commits with an empty commit message without stopping or requiring the user to specify an extra flag. (It is interesting to note that am-based rebases are the default rebase type, and no one has ever requested a --no-allow-empty-message flag to change this behavior.) merge-based and interactive-based rebases (which are ultimately based on git-commit), will currently halt on any such commits and require the user to manually specify what to do with the commit and continue. One possible rationale for the difference in behavior is that the purpose of an "am" based rebase is solely to transplant an existing history, while an "interactive" rebase is one whose purpose is to polish a series before making it publishable. Thus, stopping and asking for confirmation for a possible problem is more appropriate in the latter case. However, there are two problems with this rationale: 1) merge-based rebases are also non-interactive and there are multiple types of rebases that use the interactive machinery but are not explicitly interactive (e.g. when either --rebase-merges or --keep-empty are specified without --interactive). These rebases are also used solely to transplant an existing history, and thus also should default to --allow-empty-message. 2) this rationale only says that the user is more accepting of stopping in the case of an explicitly interactive rebase, not that stopping for this particular reason actually makes sense. Exploring whether it makes sense, requires backing up and analyzing the underlying commands... If git-commit did not error out on empty commits by default, accidental creation of commits with empty messages would be a very common occurrence (this check has caught me many times). Further, nearly all such empty commit messages would be considered an accidental error (as evidenced by a huge amount of documentation across version control systems and in various blog posts explaining how important commit messages are). A simple check for what would otherwise be a common error thus made a lot of sense, and git-commit gained an --allow-empty-message flag for special case overrides. This has made commits with empty messages very rare. There are two sources for commits with empty messages for rebase (and cherry-pick): (a) commits created in git where the user previously specified --allow-empty-message to git-commit, and (b) commits imported into git from other version control systems. In case (a), the user has already explicitly specified that there is something special about this commit that makes them not want to specify a commit message; forcing them to re-specify with every cherry-pick or rebase seems more likely to be infuriating than helpful. In case (b), the commit is highly unlikely to have been authored by the person who has imported the history and is doing the rebase or cherry-pick, and thus the user is unlikely to be the appropriate person to write a commit message for it. Stopping and expecting the user to modify the commit before proceeding thus seems counter-productive. Further, note that while empty commit messages was a common error case for git-commit to deal with, it is a rare case for rebase (or cherry-pick). The fact that it is rare raises the question of why it would be worth checking and stopping on this particular condition and not others. For example, why doesn't an interactive rebase automatically stop if the commit message's first line is 2000 columns long, or is missing a blank line after the first line, or has every line indented with five spaces, or any number of other myriad problems? Finally, note that if a user doing an interactive rebase does have the necessary knowledge to add a message for any such commit and wants to do so, it is rather simple for them to change the appropriate line from 'pick' to 'reword'. The fact that the subject is empty in the todo list that the user edits should even serve as a way to notify them. As far as I can tell, the fact that merge-based and interactive-based rebases stop on commits with empty commit messages is solely a by-product of having been based on git-commit. It went without notice for a long time precisely because such cases are rare. The rareness of this situation made it difficult to reason about, so when folks did eventually notice this behavior, they assumed it was there for a good reason and just added an --allow-empty-message flag. In my opinion, stopping on such messages not desirable in any of these cases, even the (explicitly) interactive case. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-27git-rebase.txt: document behavioral differences between modesLibravatar Elijah Newren1-0/+32
There are a variety of aspects that are common to all rebases regardless of which backend is in use; however, the behavior for these different aspects varies in ways that could surprise users. (In fact, it's not clear -- to me at least -- that these differences were even desirable or intentional.) Document these differences. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-27git-rebase.txt: address confusion between --no-ff vs --force-rebaseLibravatar Elijah Newren1-20/+10
rebase was taught the --force-rebase option in commit b2f82e05de ("Teach rebase to rebase even if upstream is up to date", 2009-02-13). This flag worked for the am and merge backends, but wasn't a valid option for the interactive backend. rebase was taught the --no-ff option for interactive rebases in commit b499549401cb ("Teach rebase the --no-ff option.", 2010-03-24), to do the exact same thing as --force-rebase does for non-interactive rebases. This commit explicitly documented the fact that --force-rebase was incompatible with --interactive, though it made --no-ff a synonym for --force-rebase for non-interactive rebases. The choice of a new option was based on the fact that "force rebase" didn't sound like an appropriate term for the interactive machinery. In commit 6bb4e485cff8 ("rebase: align variable names", 2011-02-06), the separate parsing of command line options in the different rebase scripts was removed, and whether on accident or because the author noticed that these options did the same thing, the options became synonyms and both were accepted by all three rebase types. In commit 2d26d533a012 ("Documentation/git-rebase.txt: -f forces a rebase that would otherwise be a no-op", 2014-08-12), which reworded the description of the --force-rebase option, the (no-longer correct) sentence stating that --force-rebase was incompatible with --interactive was finally removed. Finally, as explained at https://public-inbox.org/git/98279912-0f52-969d-44a6-22242039387f@xiplink.com In the original discussion around this option [1], at one point I proposed teaching rebase--interactive to respect --force-rebase instead of adding a new option [2]. Ultimately --no-ff was chosen as the better user interface design [3], because an interactive rebase can't be "forced" to run. We have accepted both --no-ff and --force-rebase as full synonyms for all three rebase types for over seven years. Documenting them differently and in ways that suggest they might not be quite synonyms simply leads to confusion. Adjust the documentation to match reality. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-27rebase: fix documentation formattingLibravatar Vladimir Parfinenko1-1/+1
Last sections are squashed into non-formatted block after adding "REBASING MERGES". To reproduce the error see bottom of page: https://git-scm.com/docs/git-rebase Signed-off-by: Vladimir Parfinenko <vparfinenko@excelsior-usa.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-26git-rebase.txt: document incompatible optionsLibravatar Elijah Newren1-8/+77
git rebase has many options that only work with one of its three backends. It also has a few other pairs of incompatible options. Document these. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>