path: root/Documentation/git-merge.txt
AgeCommit message (Collapse)Author
2021-07-22pull: update docs & code for option compatibility with rebasingElijah Newren
git-pull.txt includes merge-options.txt, which is written assuming merges will happen. git-pull has allowed rebases for many years; update the documentation to reflect that. While at it, pass any `--signoff` flag through to the rebase backend too so that we don't have to document it as merge-specific. Rebase has supported the --signoff flag for years now as well. Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2020-05-05Doc: reference the "stash list" in autostash docsDenton Liu
In documentation pertaining to autostash behavior, we refer to the "stash reflog". This description is too low-level as the reflog refers to an implementation detail of how the stash works and, for end-users, they do not need to be aware of this at all. Change references of "stash reflog" to "stash list", which should provide more accessible terminology for end-users. Signed-off-by: Denton Liu <> Signed-off-by: Junio C Hamano <>
2020-04-10merge: teach --autostash optionDenton Liu
In rebase, one can pass the `--autostash` option to cause the worktree to be automatically stashed before continuing with the rebase. This option is missing in merge, however. Implement the `--autostash` option and corresponding `merge.autoStash` option in merge which stashes before merging and then pops after. This option is useful when a developer has some local changes on a topic branch but they realize that their work depends on another branch. Previously, they had to run something like git fetch ... git stash push git merge FETCH_HEAD git stash pop but now, that is reduced to git fetch ... git merge --autostash FETCH_HEAD When an autostash is generated, it is automatically reapplied to the worktree only in three explicit situations: 1. An incomplete merge is commit using `git commit`. 2. A merge completes successfully. 3. A merge is aborted using `git merge --abort`. In all other situations where the merge state is removed using remove_merge_branch_state() such as aborting a merge via `git reset --hard`, the autostash is saved into the stash reflog instead keeping the worktree clean. Helped-by: Phillip Wood <> Suggested-by: Alban Gruin <> Signed-off-by: Denton Liu <> Signed-off-by: Junio C Hamano <>
2019-08-07merge: do no-verify like commitMichael J Gruber
f8b863598c ("builtin/merge: honor commit-msg hook for merges", 2017-09-07) introduced the no-verify flag to merge for bypassing the commit-msg hook, though in a different way from the implementation in commit.c. Change the implementation in merge.c to be the same as in commit.c so that both do the same in the same way. This also changes the output of "git merge --help" to be more clear that the hook return code is respected by default. [js: * reworded commit message * squashed documentation changes from original series' patch 3/4 ] Signed-off-by: Michael J Gruber <> Signed-off-by: Josh Steadmon <> Signed-off-by: Junio C Hamano <>
2019-07-09Merge branch 'nd/switch-and-restore'Junio C Hamano
Two new commands "git switch" and "git restore" are introduced to split "checking out a branch to work on advancing its history" and "checking out paths out of the index and/or a tree-ish to work on advancing the current history" out of the single "git checkout" command. * nd/switch-and-restore: (46 commits) completion: disable dwim on "git switch -d" switch: allow to switch in the middle of bisect t2027: use test_must_be_empty Declare both git-switch and git-restore experimental help: move git-diff and git-reset to different groups doc: promote "git restore" user-manual.txt: prefer 'merge --abort' over 'reset --hard' completion: support restore t: add tests for restore restore: support --patch restore: replace --force with --ignore-unmerged restore: default to --source=HEAD when only --staged is specified restore: reject invalid combinations with --staged restore: add --worktree and --staged checkout: factor out worktree checkout code restore: disable overlay mode by default restore: make pathspec mandatory restore: take tree-ish from --source option instead checkout: split part of it to new command 'restore' doc: promote "git switch" ...
2019-07-09Merge branch 'pw/doc-synopsis-markup-opmode-options'Junio C Hamano
Docfix. * pw/doc-synopsis-markup-opmode-options: show --continue/skip etc. consistently in synopsis
2019-06-18show --continue/skip etc. consistently in synopsisPhillip Wood
Command mode options that the user can choose one among many are listed like this in the documentation: git am (--continue | --skip | --abort | --quit) They are listed on a single line and in parenthesis, because they are not optional. But documentation pages for some commands deviate from this norm. Fix the merge and rebase docs to match this style. Signed-off-by: Phillip Wood <> Signed-off-by: Junio C Hamano <>
2019-06-13Merge branch 'nd/merge-quit'Junio C Hamano
"git merge" learned "--quit" option that cleans up the in-progress merge while leaving the working tree and the index still in a mess. * nd/merge-quit: merge: add --quit merge: remove drop_save() in favor of remove_merge_branch_state()
2019-05-19merge: add --quitNguyễn Thái Ngọc Duy
This allows to cancel the current merge without resetting worktree/index, which is what --abort is for. Like other --quit(s), this is often used when you forgot that you're in the middle of a merge and already switched away, doing different things. By the time you've realized, you can't even continue the merge anymore. This also makes all in-progress commands, am, merge, rebase, revert and cherry-pick, take all three --abort, --continue and --quit (bisect has a different UI). Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02doc: document --overwrite-ignoreNguyễn Thái Ngọc Duy
I added this option in git-checkout and git-merge in c1d7036b6b (checkout,merge: disallow overwriting ignored files with --no-overwrite-ignore - 2011-11-27) but did not remember to update documentation. This completes that commit. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-03-18merge: tweak --rerere-autoupdate documentationPhillip Wood
Spell out --no-rerere-autoupdate explictly to make searching easier. This matches the other --no options in the man page. Signed-off-by: Phillip Wood <> Signed-off-by: Junio C Hamano <>
2018-10-29config.txt: move merge-config.txt to config/Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-08-02Merge branch 'en/dirty-merge-fixes'Junio C Hamano
The recursive merge strategy did not properly ensure there was no change between HEAD and the index before performing its operation, which has been corrected. * en/dirty-merge-fixes: merge: fix misleading pre-merge check documentation merge-recursive: enforce rule that index matches head before merging t6044: add more testcases with staged changes before a merge is invoked merge-recursive: fix assumption that head tree being merged is HEAD merge-recursive: make sure when we say we abort that we actually abort t6044: add a testcase for index matching head, when head doesn't match HEAD t6044: verify that merges expected to abort actually abort index_has_changes(): avoid assuming operating on the_index read-cache.c: move index_has_changes() from merge.c
2018-07-11merge: allow reading the merge commit message from a fileJohannes Schindelin
This is consistent with `git commit` which, like `git merge`, supports passing the commit message via `-m <msg>` and, unlike `git merge` before this patch, via `-F <file>`. It is useful to allow this for scripted use, or for the upcoming patch to allow (re-)creating octopus merges in `git rebase --rebase-merges`. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-07-11merge: fix misleading pre-merge check documentationElijah Newren
builtin/merge.c contains this important requirement for merge strategies: ...the index must be in sync with the head commit. The strategies are responsible to ensure this. However, Documentation/git-merge.txt says: ...[merge will] abort if there are any changes registered in the index relative to the `HEAD` commit. (One exception is when the changed index entries are in the state that would result from the merge already.) Interestingly, prior to commit c0be8aa06b85 ("Documentation/git-merge.txt: Partial rewrite of How Merge Works", 2008-07-19), Documentation/git-merge.txt said much more: ...the index file must match the tree of `HEAD` commit... [NOTE] This is a bit of a lie. In certain special cases [explained in detail]... Otherwise, merge will refuse to do any harm to your repository (that is...your working tree...and index are left intact). So, this suggests that the exceptions existed because there were special cases where it would case no harm, and potentially be slightly more convenient for the user. While the current text in git-merge.txt does list a condition under which it would be safe to proceed despite the index not matching HEAD, it does not match what is actually implemented, in three different ways: * The exception is written to describe what unpack-trees allows. Not all merge strategies allow such an exception, though, making this description misleading. 'ours' and 'octopus' merges have strictly enforced index==HEAD for a while, and the commit previous to this one made 'recursive' do so as well. * If someone did a three-way content merge on a specific file using versions from the relevant commits and staged it prior to running merge, then that path would technically satisfy the exception listed in git-merge.txt. unpack-trees.c would still error out on the path, though, because it defers the three-way content merge logic to other parts of the code (resolve, octopus, or recursive) and has no way of checking whether the index entry from before the merge will match the end result of the merge. * The exception as implemented in unpack-trees actually only checked that the index matched the MERGE_HEAD version of the file and that HEAD matched the merge base. Assuming no renames, that would indeed provide cases where the index matches the end result we'd get from a merge. But renames means unpack-trees is checking that it instead matches something other than what the final result will be, risking either erroring out when we shouldn't need to, or not erroring out when we should and overwriting the user's staged changes. In addition to the wording behind this exception being misleading, it is also somewhat surprising to see how many times the code for the special cases were wrong or the check to make sure the index matched head was forgotten altogether: * Prior to commit ee6566e8d70d ("[PATCH] Rewrite read-tree", 2005-09-05), there were many cases where an unclean index entry was allowed (look for merged_entry_allow_dirty()); it appears that in those cases, the merge would have simply overwritten staged changes with the result of the merge. Thus, the merge result would have been correct, but the user's uncommitted changes could be thrown away without warning. * Prior to commit 160252f81626 ("git-merge-ours: make sure our index matches HEAD", 2005-11-03), the 'ours' merge strategy did not check whether the index matched HEAD. If it didn't, the resulting merge would include all the staged changes, and thus wasn't really an 'ours' strategy. * Prior to commit 3ec62ad9ffba ("merge-octopus: abort if index does not match HEAD", 2016-04-09), 'octopus' merges did not check whether the index matched HEAD, also resulting in any staged changes from before the commit silently being folded into the resulting merge. commit a6ee883b8eb5 ("t6044: new merge testcases for when index doesn't match HEAD", 2016-04-09) was also added at the same time to try to test to make sure all strategies did the necessary checking for the requirement that the index match HEAD. Sadly, it didn't catch all the cases, as evidenced by the remainder of this list... * Prior to commit 65170c07d466 ("merge-recursive: avoid incorporating uncommitted changes in a merge", 2017-12-21), merge-recursive simply relied on unpack_trees() to do the necessary check, but in one special case it avoided calling unpack_trees() entirely and accidentally ended up silently including any staged changes from before the merge in the resulting merge commit. * The commit immediately before this one in this series noted that the exceptions were written in a way that assumed no renames, making it unsafe for merge-recursive to use. merge-recursive was modified to use its own check to enforce that index==HEAD. This history makes it very tempting to go into builtin/merge.c and replace the comment that strategies must enforce that index matches HEAD with code that just enforces it. At this point, that would only affect the 'resolve' strategy; all other strategies have each been modified to manually enforce it. (However, note that index==HEAD is not strictly enforced for fast-forward merges, as those are not considered a merge strategy and they trigger in builtin/merge.c before the section in the code where the relevant comment is found.) But, even if we don't take the step of just fixing these problems by enforcing index==HEAD for all strategies, we at least need to update this misleading documentation in git-merge.txt. For now, just modify the claim in Documentation/git-merge.txt to fix the error. The precise details around combination of merges strategies and special cases probably is not relevant to most users, so simply state that exceptions may exist but are narrow and vary depending upon which merge strategy is in use. Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2018-06-18Merge branch 'mw/doc-merge-enumfix'Junio C Hamano
Fix old merge glitch in Documentation during v2.13-rc0 era. * mw/doc-merge-enumfix: doc: update the order of the syntax `git merge --continue`
2018-06-14doc: update the order of the syntax `git merge --continue`Meng-Sung Wu
The syntax "git merge <message> HEAD <commit>" has been removed. The order of the syntax should also be updated. Signed-off-by: Meng-Sung Wu <> Signed-off-by: Junio C Hamano <>
2017-11-06Merge branch 'wk/pull-signoff'Junio C Hamano
"git pull" has been taught to accept "--[no-]signoff" option and pass it down to "git merge". * wk/pull-signoff: pull: pass --signoff/--no-signoff to "git merge"
2017-10-19Merge branch 'wk/merge-options-gpg-sign-doc'Junio C Hamano
Doc updates. * wk/merge-options-gpg-sign-doc: Documentation/merge-options.txt: describe -S/--gpg-sign for 'pull'
2017-10-13pull: pass --signoff/--no-signoff to "git merge"W. Trevor King
merge can take --signoff, but without pull passing --signoff down, it is inconvenient to use; allow 'pull' to take the option and pass it through. The order of options in merge-options.txt is mostly alphabetical by long option since 7c85d274 (Documentation/merge-options.txt: order options in alphabetical groups, 2009-10-22). The long-option bit didn't make it into the commit message, but it's under the fold in [1]. I've put --signoff between --log and --stat to preserve the alphabetical order. [1]: Signed-off-by: W. Trevor King <> Signed-off-by: Junio C Hamano <>
2017-10-12Documentation/merge-options.txt: describe -S/--gpg-sign for 'pull'W. Trevor King
Pull has supported these since ea230d8 (pull: add the --gpg-sign option, 2014-02-10). Insert in long-option alphabetical order following 7c85d274 (Documentation/merge-options.txt: order options in alphabetical groups, 2009-10-22). Signed-off-by: W. Trevor King <> Signed-off-by: Junio C Hamano <>
2017-09-10Merge branch 'ma/up-to-date'Junio C Hamano
Message and doc updates. * ma/up-to-date: treewide: correct several "up-to-date" to "up to date" Documentation/user-manual: update outdated example output
2017-08-27Merge branch 'mg/killed-merge'Junio C Hamano
Killing "git merge --edit" before the editor returns control left the repository in a state with MERGE_MSG but without MERGE_HEAD, which incorrectly tells the subsequent "git commit" that there was a squash merge in progress. This has been fixed. * mg/killed-merge: merge: save merge state earlier merge: split write_merge_state in two merge: clarify call chain Documentation/git-merge: explain --continue
2017-08-23treewide: correct several "up-to-date" to "up to date"Martin Ågren
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 <> Reported-by: STEVEN WHITE <> Signed-off-by: Martin Ågren <> Signed-off-by: Junio C Hamano <>
2017-08-22Documentation/git-merge: explain --continueMichael J Gruber
Currently, 'git merge --continue' is mentioned but not explained. Explain it. Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2017-07-25merge: add a --signoff flagŁukasz Gryglicki
Some projects require every commit, even merges, to be signed off [*1*]. Because "git merge" does not have a "--signoff" option like "git commit" does, the user needs to add one manually when the command presents an editor to describe the merge, or later use "git commit --amend --signoff". Help developers of these projects by teaching "--signoff" option to "git merge". *1* Requested-by: Dan Kohn <> Signed-off-by: Łukasz Gryglicki <> Signed-off-by: Junio C Hamano <>
2017-03-30Merge branch 'jc/merge-drop-old-syntax'Junio C Hamano
Stop supporting "git merge <message> HEAD <commit>" syntax that has been deprecated since October 2007, and issues a deprecation warning message since v2.5.0. * jc/merge-drop-old-syntax: merge: drop 'git merge <message> HEAD <commit>' syntax
2016-12-14merge: add '--continue' option as a synonym for 'git commit'Chris Packham
Teach 'git merge' the --continue option which allows 'continuing' a merge by completing it. The traditional way of completing a merge after resolving conflicts is to use 'git commit'. Now with commands like 'git rebase' and 'git cherry-pick' having a '--continue' option adding such an option to 'git merge' presents a consistent UI. Signed-off-by: Chris Packham <> Signed-off-by: Junio C Hamano <>
2016-04-21pull: pass --allow-unrelated-histories to "git merge"Junio C Hamano
The previous commit said: We could add the same option to "git pull" and have it passed through to underlying "git merge". I do not have a fundamental opposition against such a feature, but this commit does not do so and instead leaves it as low-hanging fruit for others, because such a "two project merge" would be done after fetching the other project into some location in the working tree of an existing project and making sure how well they fit together, it is sufficient to allow a local merge without such an option pass-through from "git pull" to "git merge". Prepare a patch to make it a reality, just in case it is needed. Signed-off-by: Junio C Hamano <>
2016-03-23merge: refuse to create too cool a merge by defaultJunio C Hamano
While it makes sense to allow merging unrelated histories of two projects that started independently into one, in the way "gitk" was merged to "git" itself aka "the coolest merge ever", such a merge is still an unusual event. Worse, if somebody creates an independent history by starting from a tarball of an established project and sends a pull request to the original project, "git merge" however happily creates such a merge without any sign of something unusual is happening. Teach "git merge" to refuse to create such a merge by default, unless the user passes a new "--allow-unrelated-histories" option to tell it that the user is aware that two unrelated projects are merged. Because such a "two project merge" is a rare event, a configuration option to always allow such a merge is not added. We could add the same option to "git pull" and have it passed through to underlying "git merge". I do not have a fundamental opposition against such a feature, but this commit does not do so and instead leaves it as low-hanging fruit for others, because such a "two project merge" would be done after fetching the other project into some location in the working tree of an existing project and making sure how well they fit together, it is sufficient to allow a local merge without such an option pass-through from "git pull" to "git merge". Many tests that are updated by this patch does the pass-through manually by turning: git pull something into its equivalent: git fetch something && git merge --allow-unrelated-histories FETCH_HEAD If somebody is inclined to add such an option, updated tests in this change need to be adjusted back to: git pull --allow-unrelated-histories something Signed-off-by: Junio C Hamano <>
2015-10-05Merge branch 'mm/keyid-docs'Junio C Hamano
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-09-21Documentation: explain optional arguments betterMatthieu Moy
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 <> Reviewed-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-09-21Documentation: use 'keyid' consistently, not 'key-id'Matthieu Moy
Signed-off-by: Matthieu Moy <> Reviewed-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-09-17Merge branch 'po/doc-branch-desc'Junio C Hamano
The branch descriptions that are set with "git branch --edit-description" option were used in many places but they weren't clearly documented. * po/doc-branch-desc: doc: show usage of branch description
2015-09-14doc: show usage of branch descriptionPhilip Oakley
The branch description will be included in 'git format-patch --cover-letter' and in 'git pull-request' emails. It can also be used in the automatic merge message. Tell the reader. While here, clarify that the description may be a multi-line explanation of the purpose of the branch's patch series. Signed-off-by: Philip Oakley <> Signed-off-by: Junio C Hamano <>
2015-05-19Merge branch 'jc/merge'Junio C Hamano
"git merge FETCH_HEAD" learned that the previous "git fetch" could be to create an Octopus merge, i.e. recording multiple branches that are not marked as "not-for-merge"; this allows us to lose an old style invocation "git merge <msg> HEAD $commits..." in the implementation of "git pull" script; the old style syntax can now be deprecated. * jc/merge: merge: deprecate 'git merge <message> HEAD <commit>' syntax merge: handle FETCH_HEAD internally merge: decide if we auto-generate the message early in collect_parents() merge: make collect_parents() auto-generate the merge message merge: extract prepare_merge_message() logic out merge: narrow scope of merge_names merge: split reduce_parents() out of collect_parents() merge: clarify collect_parents() logic merge: small leakfix and code simplification merge: do not check argc to determine number of remote heads merge: clarify "pulling into void" special case t5520: test pulling an octopus into an unborn branch t5520: style fixes merge: simplify code flow merge: test the top-level merge driver
2015-04-29merge: drop 'git merge <message> HEAD <commit>' syntaxJunio C Hamano
And then if we and our users survived the previous "start warning if the old syntax is used" patch for a few years, we could apply this to actually drop the support for the ancient syntax. Signed-off-by: Junio C Hamano <>
2015-04-29merge: handle FETCH_HEAD internallyJunio C Hamano
The collect_parents() function now is responsible for 1. parsing the commits given on the command line into a list of commits to be merged; 2. filtering these parents into independent ones; and 3. optionally calling fmt_merge_msg() via prepare_merge_message() to prepare an auto-generated merge log message, using fake contents that FETCH_HEAD would have had if these commits were fetched from the current repository with "git pull . $args..." Make "git merge FETCH_HEAD" to be the same as the traditional git merge "$(git fmt-merge-msg <.git/FETCH_HEAD)" $commits invocation of the command in "git pull", where $commits are the ones that appear in FETCH_HEAD that are not marked as not-for-merge, by making it do a bit more, specifically: - noticing "FETCH_HEAD" is the only "commit" on the command line and picking the commits that are not marked as not-for-merge as the list of commits to be merged (substitute for step #1 above); - letting the resulting list fed to step #2 above; - doing the step #3 above, using the contents of the FETCH_HEAD instead of fake contents crafted from the list of commits parsed in the step #1 above. Note that this changes the semantics. "git merge FETCH_HEAD" has always behaved as if the first commit in the FETCH_HEAD file were directly specified on the command line, creating a two-way merge whose auto-generated merge log said "merge commit xyz". With this change, if the previous fetch was to grab multiple branches (e.g. "git fetch $there topic-a topic-b"), the new world order is to create an octopus, behaving as if "git pull $there topic-a topic-b" were run. This is a deliberate change to make that happen, and can be seen in the changes to t3033 tests. Signed-off-by: Junio C Hamano <>
2015-03-14*config.txt: stick to camelCase naming conventionNguyễn Thái Ngọc Duy
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 <> Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Eric Sunshine <> Signed-off-by: Junio C Hamano <>
2014-04-22merge: enable defaulttoupstream by defaultFelipe Contreras
There's no point in this: % git merge fatal: No commit specified and merge.defaultToUpstream not set. We know the most likely scenario is that the user wants to merge the upstream, and if not, he can set merge.defaultToUpstream to false. Signed-off-by: Felipe Contreras <> Signed-off-by: Junio C Hamano <>
2014-03-24parse-options: multi-word argh should use dash to separate wordsJunio C Hamano
"When you need to use space, use dash" is a strange way to say that you must not use a space. Because it is more common for the command line descriptions to use dashed-multi-words, you do not even want to use spaces in these places. Rephrase the documentation to avoid this strangeness. Fix a few existing multi-word argument help strings, i.e. - GPG key-ids given to -S/--gpg-sign are "key-id"; - Refs used for storing notes are "notes-ref"; and - Expiry timestamps given to --expire are "expiry-date". and update the corresponding documentation pages. Signed-off-by: Junio C Hamano <>
2013-10-18git-merge: document the -S optionNicolas Vigier
The option to gpg sign a merge commit is available but was not documented. Use wording from the git-commit(1) manpage. Signed-off-by: Nicolas Vigier <> Signed-off-by: Junio C Hamano <>
2013-09-05Merge branch 'maint-1.8.2' into maint-1.8.3Junio C Hamano
* maint-1.8.2: Documentation/git-merge.txt: fix formatting of example block
2013-09-05Documentation/git-merge.txt: fix formatting of example blockAndreas Schwab
You need at least four dashes in a line to have it recognized as listing block delimiter by asciidoc. Signed-off-by: Andreas Schwab <> Signed-off-by: Junio C Hamano <>
2013-07-22Merge branch 'mm/merge-in-dirty-worktree-doc' into maintJunio C Hamano
* mm/merge-in-dirty-worktree-doc: Documentation/git-merge.txt: weaken warning about uncommited changes
2013-06-18Documentation/git-merge.txt: weaken warning about uncommited changesMatthieu Moy
Commit 35d2fffd introduced 'git merge --abort' as a synonym to 'git reset --merge', and added some failing tests in (search '###' in this file) showing that 'git merge --abort' could not always recover the pre-merge state. Still, in many cases, 'git merge --abort' just works, and it is usually considered that the ability to start a merge with uncommited changes is an important property of Git. Weaken the warning by discouraging only merge with /non-trivial/ uncommited changes. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2013-05-17documentation: trivial style cleanupsFelipe Contreras
White-spaces, missing braces, standardize --[no-]foo. Signed-off-by: Felipe Contreras <> Signed-off-by: Junio C Hamano <>
2013-04-01Merge branch 'yd/doc-merge-annotated-tag' into maintJunio C Hamano
* yd/doc-merge-annotated-tag: Documentation: merging a tag is a special case
2013-03-28Merge branch 'yd/doc-merge-annotated-tag'Junio C Hamano
Document the 1.7.9 feature to merge a signed tag and keep that in the mergetag header in the resulting commit better. * yd/doc-merge-annotated-tag: Documentation: merging a tag is a special case
2013-03-21Documentation: merging a tag is a special caseJunio C Hamano
When asking Git to merge a tag (such as a signed tag or annotated tag), it will always create a merge commit even if fast-forward was possible. It's like having --no-ff present on the command line. It's a difference from the default behavior described in git-merge.txt. It should be documented as an exception of "FAST-FORWARD MERGE" section and "--ff" option description. Reviewed-by: Jonathan Nieder <> Reviewed-by: Yann Droneaud <> Signed-off-by: Junio C Hamano <>