path: root/t/
AgeCommit message (Collapse)Author
2020-06-24fmt-merge-msg: stop treating `master` speciallyJohannes Schindelin
In the context of many projects renaming their primary branch names away from `master`, Git wants to stop treating the `master` branch specially. Let's start with `git fmt-merge-msg`. Signed-off-by: Johannes Schindelin <> 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 <>
2020-03-24t7600: use test_write_lines()Denton Liu
In t7600, we were rewriting `printf '%s\n' ...` to create files from parameters, one per line. However, we already have a function that wraps this for us: test_write_lines(). Rewrite these instances to use that function instead of open coding it. Signed-off-by: Denton Liu <> Signed-off-by: Junio C Hamano <>
2019-06-17Merge branch 'vv/merge-squash-with-explicit-commit'Junio C Hamano
"git merge --squash" is designed to update the working tree and the index without creating the commit, and this cannot be countermanded by adding the "--commit" option; the command now refuses to work when both options are given. * vv/merge-squash-with-explicit-commit: merge: refuse --commit with --squash
2019-06-13Merge branch 'jk/help-unknown-ref-fix'Junio C Hamano
Improve the code to show args with potential typo that cannot be interpreted as a commit-ish. * jk/help-unknown-ref-fix: help_unknown_ref(): check for refname ambiguity help_unknown_ref(): duplicate collected refnames
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-28merge: refuse --commit with --squashVishal Verma
Convert option_commit to tristate, representing the states of 'default/untouched', 'enabled-by-cli', 'disabled-by-cli'. With this in place, check whether option_commit was enabled by cli when squashing a merge. If so, error out, as this is not supported. Previously, when --squash was supplied, 'option_commit' was silently dropped. This could have been surprising to a user who tried to override the no-commit behavior of squash using --commit explicitly. Add a note to the --squash option for git-merge to clarify the incompatibility, and add a test case to Cc: Junio C Hamano <> Cc: Rafael Ascensão <> Cc: Johannes Schindelin <> Signed-off-by: Vishal Verma <> Signed-off-by: Junio C Hamano <>
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-05-15help_unknown_ref(): check for refname ambiguityJeff King
When the user asks to merge "foo" and we suggest "origin/foo" instead, we do so by simply chopping off "refs/remotes/" from the front of the suggested ref. This is usually fine, but it's possible that the resulting name is ambiguous (e.g., you have "refs/heads/origin/foo", too). Let's use shorten_unambiguous_ref() to do this the right way, which should usually yield the same "origin/foo", but "remotes/origin/foo" if necessary. Note that in this situation there may be other options (e.g., we could suggest "heads/origin/foo" as well). I'll leave that up for debate; the focus here is just to avoid giving advice that does not actually do what we expect. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2019-05-15help_unknown_ref(): duplicate collected refnamesJeff King
When "git merge" sees an unknown refname, we iterate through the refs to try to suggest some possible alternates. We do so with for_each_ref(), and in the callback we add some of the refnames we get to a string_list that is declared with NODUP, directly adding a pointer into the refname string our callback received. But the for_each_ref() machinery does not promise that the refname string will remain valid, and as a result we may print garbage memory. The code in question dates back to its inception in e56181060e (help: add help_unknown_ref(), 2013-05-04). But back then, the refname strings generally did remain stable, at least immediately after the for_each_ref() call. Later, in d1cf15516f (packed_ref_iterator_begin(): iterate using `mmapped_ref_iterator`, 2017-09-25), we started consistently re-using a separate buffer for packed refs. The fix is simple: duplicate the strings we intend to collect. We already call string_list_clear(), so the memory is correctly freed. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2019-04-18merge: add scissors line on merge conflictDenton Liu
This fixes a bug where the scissors line is placed after the Conflicts: section, in the case where a merge conflict occurs and commit.cleanup = scissors. Next, if commit.cleanup = scissors is specified, don't produce a scissors line in commit if one already exists in the MERGE_MSG file. Helped-by: Eric Sunshine <> Signed-off-by: Denton Liu <> Signed-off-by: Junio C Hamano <>
2019-04-18t7600: clean up styleDenton Liu
Clean up the 'merge --squash c3 with c7' test by removing some unnecessary braces and removing a pipe. Also, generally cleanup style by unindenting a here-doc, removing stray spaces after a redirection operator and allowing sed to open its own input instead of redirecting input from the shell. Helped-by: SZEDER Gábor <> Helped-by: Eric Sunshine <> Helped-by: Junio C Hamano <> Signed-off-by: Denton Liu <> Signed-off-by: Junio C Hamano <>
2018-08-21tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'SZEDER Gábor
Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in '', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in ''. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in ''. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in ''. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2018-02-16merge: allow fast-forward when merging a tracked tagJunio C Hamano
Long time ago at fab47d05 ("merge: force edit and no-ff mode when merging a tag object", 2011-11-07), "git merge" was made to always create a merge commit when merging a tag, even when the side branch being merged is a descendant of the current branch. This default is good for merges made by upstream maintainers to integrate work signed by downstream contributors, but will leave pointless no-ff merges when downstream contributors pull a newer release tag to make their long-running topic branches catch up with the upstream. When there is no local work left on the topic, such a merge should simply fast-forward to the commit pointed at by the release tag. Update the default (again) for "git merge" that merges a tag object to (1) --no-ff (i.e. create a merge commit even when side branch fast forwards) if the tag being merged is not at its expected place in refs/tags/ hierarchy and (2) --ff (i.e. allow fast-forward update when able) otherwise. Signed-off-by: Junio C Hamano <>
2017-10-07tests: fix diff order arguments in test_cmpStefan Beller
Fix the argument order for test_cmp. When given the expected result first the diff shows the actual output with '+' and the expectation with '-', which is the convention for our tests. Signed-off-by: Stefan Beller <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2017-08-23merge: save merge state earlierMichael J Gruber
If the `git merge` process is killed while waiting for the editor to finish, the merge state is lost but the prepared merge msg and tree is kept. So, a subsequent `git commit` creates a squashed merge even when the user asked for proper merge commit originally. Demonstrate the problem with a test crafted after the in t7502. The test requires EXECKEEPSPID (thus does not run under MINGW). Save the merge state earlier (in the non-squash case) so that it does not get lost. This makes the test pass. Reported-by: hIpPy <> Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2016-12-14merge: ensure '--abort' option takes no argumentsChris Packham
Like '--continue', the '--abort' option doesn't make any sense with other options or arguments to 'git merge' so ensure that none are present. Signed-off-by: Chris Packham <> Signed-off-by: Junio C Hamano <>
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-06Merge branch 'jv/merge-nothing-into-void'Junio C Hamano
"git merge FETCH_HEAD" dereferenced NULL pointer when merging nothing into an unborn history (which is arguably unusual usage, which perhaps was the reason why nobody noticed it). * jv/merge-nothing-into-void: merge: fix NULL pointer dereference when merging nothing into void
2016-04-06Merge branch 'ss/commit-squash-msg'Junio C Hamano
When "git merge --squash" stopped due to conflict, the concluding "git commit" failed to read in the SQUASH_MSG that shows the log messages from all the squashed commits. * ss/commit-squash-msg: commit: do not lose SQUASH_MSG contents
2016-03-23merge: fix NULL pointer dereference when merging nothing into voidJunio C Hamano
When we are on an unborn branch and merging only one foreign parent, we allow "git merge" to fast-forward to that foreign parent commit. This codepath incorrectly attempted to dereference the list of parents that the merge is going to record even when the list is empty. It must refuse to operate instead when there is no parent. All other codepaths make sure the list is not empty before they dereference it, and are safe. Reported-by: Jose Ivan B. Vilarouca Filho Signed-off-by: Junio C Hamano <>
2016-03-21commit: do not lose SQUASH_MSG contentsSven Strickroth
When concluding a conflicted "git merge --squash", the command failed to read SQUASH_MSG that was prepared by "git merge", and showed only the "# Conflicts:" list of conflicted paths. Place the contents from SQUASH_MSG at the beginning, just like we show the commit log skeleton first when concluding a normal merge, and then show the "# Conflicts:" list, to help the user write the log message for the resulting commit. Test by Junio C Hamano <>. Signed-off-by: Sven Strickroth <> Signed-off-by: Junio C Hamano <>
2015-10-30Merge branch 'jk/merge-file-exit-code'Junio C Hamano
"git merge-file" tried to signal how many conflicts it found, which obviously would not work well when there are too many of them. * jk/merge-file-exit-code: merge-file: clamp exit code to maximum 127
2015-10-29merge-file: clamp exit code to maximum 127Jeff King
Git-merge-file is documented to return one of three exit codes: - zero means the merge was successful - a negative number means an error occurred - a positive number indicates the number of conflicts Unfortunately, this all gets stuffed into an 8-bit return code. Which means that if you have 256 conflicts, this wraps to zero, and the merge appears to succeed (and commits a blob full of conflict-marker cruft!). This patch clamps the return value to a maximum of 127, which we should be able to safely represent everywhere. This also leaves 128-255 for other values. Shells (and some parts of git) will typically represent signal death as 128 plus the signal number. And negative values are typically coerced to an 8-bit unsigned value (so "return -1" ends up as 255). Technically negative returns have the same problem (e.g., "-256" wraps back to 0), but this is not a problem in practice, as the only negative value we use is "-1". Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-03-20t: fix trivial &&-chain breakageJeff King
These are tests which are missing a link in their &&-chain, but during a setup phase. We may fail to notice failure in commands that build the test environment, but these are typically not expected to fail at all (but it's still good to double-check that our test environment is what we expect). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-05-15git-show: fix 'git show -s' to not add extra terminator after merge commitMax Kirillov
When git show -s is called for merge commit it prints extra newline after any merge commit. This differs from output for commits with one parent. Fix it by more thorough checking that diff output is disabled. The code in question exists since commit 3969cf7db1. The additional newline is really needed for cases when patch is requested, test contains cases which can demonstrate behavior when the condition is restricted further. Tests: Added merge commit to 'set up a bit of history' case in to cover the fix. Existing tests are updated to demonstrate the new behaviour. Earlier, the tests that used "git show -s --pretty=format:%s", even though "--pretty=format:%s" calls for item separator semantics and does not ask for the terminating newline after the last item, expected the output to end with such a newline. They were relying on the buggy behaviour. Use of "--format=%s", which is equivalent to "--pretty=tformat:%s" that asks for a terminating newline after each item, is a more realistic way to use the command. In the test 'merge log messages' the expected data is changed, because it was explicitly listing the extra newline. Also the msg.nologff and msg.nolognoff expected files are replaced by one msg.nolog, because they were diffing because of the bug, and now there should be no difference. Signed-off-by: Max Kirillov <> Signed-off-by: Junio C Hamano <>
2013-07-23t7600: fix typo in test titleJunio C Hamano
Spotted by Ram, confirmed by Miklos. Signed-off-by: Junio C Hamano <>
2013-07-02merge: handle --ff/--no-ff/--ff-only as a tri-state optionMiklos Vajna
These three options mean "favor fast-forwarding when possible, without creating an unnecessary merge", "never fast-forward and always create a merge commit even when the commit being merged is a strict descendant", and "we do not want to create any merge commit; update only when the merged commit is a strict descendant". They are "pick one out of these three possibilities" options, and correspond to "merge.ff" configuration that is tri-state (yes, no and only). However, the implementation did not follow the usual convention for the command line options (later one wins, and command line overrides what is in the configuration). Fix this by consolidating two variables (fast_forward_only and allow_fast_forward) used in the implementation into one enum that can take one of the three possible values. Signed-off-by: Miklos Vajna <> Signed-off-by: Junio C Hamano <>
2013-06-26Merge branch 'vl/typofix'Junio C Hamano
* vl/typofix: random typofixes (committed missing a 't', successful missing an 's')
2013-06-19random typofixes (committed missing a 't', successful missing an 's')Veres Lajos
Signed-off-by: Veres Lajos <> Signed-off-by: Junio C Hamano <>
2013-03-25t7600: use test_config to set/unset git config variablesYann Droneaud
Instead of using construct such as: test_when_finished "git config --unset <key>" git config <key> <value> uses test_config <key> <value> The latter takes care of removing <key> at the end of the test. Tests are modified to assume default configuration at entry, and to reset the modified configuration variables at the end. Test 'merge log message' was relying on the presence of option `--no-ff` in the configuration. With the option, git show -s --pretty=format:%b HEAD produces an empty line and without the option, it produces an empty file. The test is modified to check with and without `--no-ff` option. Signed-off-by: Yann Droneaud <> Signed-off-by: Junio C Hamano <>
2012-08-27Fix tests under GETTEXT_POISON on parseoptJiang Xin
Use the i18n-specific test functions in test scripts for parseopt tests. This issue was was introduced in v1.7.10.1-488-g54e6d: 54e6d i18n: parseopt: lookup help and argument translations when showing usage and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <> Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2012-02-09merge: do not launch an editor on "--no-edit $tag"Junio C Hamano
When the user explicitly asked us not to, don't launch an editor. But do everything else the same way as the "edit" case, i.e. leave the comment with verification result in the log template and record the mergesig in the resulting merge commit for later inspection. Based on initiail analysis by Jonathan Nieder. Signed-off-by: Junio C Hamano <>
2012-02-06merge: do not create a signed tag merge under --ff-only optionJunio C Hamano
Starting at release v1.7.9, if you ask to merge a signed tag, "git merge" always creates a merge commit, even when the tag points at a commit that happens to be a descendant of your current commit. Unfortunately, this interacts rather badly for people who use --ff-only to make sure that their branch is free of local developments. It used to be possible to say: $ git checkout -b frotz v1.7.9~30 $ git merge --ff-only v1.7.9 and expect that the resulting tip of frotz branch matches v1.7.9^0 (aka the commit tagged as v1.7.9), but this fails with the updated Git with: fatal: Not possible to fast-forward, aborting. because a merge that merges v1.7.9 tag to v1.7.9~30 cannot be created by fast forwarding. We could teach users that now they have to do $ git merge --ff-only v1.7.9^0 but it is far more pleasant for users if we DWIMmed this ourselves. When an integrator pulls in a topic from a lieutenant via a signed tag, even when the work done by the lieutenant happens to fast-forward, the integrator wants to have a merge record, so the integrator will not be asking for --ff-only when running "git pull" in such a case. Therefore, this change should not regress the support for the use case v1.7.9 wanted to add. Signed-off-by: Junio C Hamano <>
2011-11-08merge: record tag objects without peeling in MERGE_HEADJunio C Hamano
Otherwise, "git commit" wouldn't have a way to tell that we were in the middle of merging an annotated or signed tag, not a plain commit, after "git merge" stops to ask the user to resolve conflicts. Signed-off-by: Junio C Hamano <>
2011-11-07merge: notice local merging of tags and keep it unwrappedJunio C Hamano
This also updates the autogenerated merge title message from "merge commit X" to "merge tag X", and its effect can be seen in the changes to the test suite. Signed-off-by: Junio C Hamano <>
2011-10-12Teach merge the '[-e|--edit]' optionJay Soffian
Implemented internally instead of as "git merge --no-commit && git commit" so that "merge --edit" is otherwise consistent (hooks, etc) with "merge". Note: the edit message does not include the status information that one gets with "commit --status" and it is cleaned up after editing like one gets with "commit --cleanup=default". A later patch could add the status information if desired. Note: previously we were not calling stripspace() after running the prepare-commit-msg hook. Now we are, stripping comments and leading/trailing whitespace lines if --edit is given, otherwise only stripping leading/trailing whitespace lines if not given --edit. Signed-off-by: Jay Soffian <> Signed-off-by: Junio C Hamano <>
2011-05-16Merge branch 'mg/merge-ff-config'Junio C Hamano
* mg/merge-ff-config: tests: check git does not barf on merge.ff values for future versions of git merge: introduce merge.ff configuration variable Conflicts: t/
2011-05-11Merge branch 'jc/maint-branch-mergeoptions'Junio C Hamano
* jc/maint-branch-mergeoptions: merge: make branch.<name>.mergeoptions correctly override merge.<option> Conflicts: builtin/merge.c
2011-05-11Merge branch 'jn/maint-test-merge-verify-parents'Junio C Hamano
* jn/maint-test-merge-verify-parents: tests: teach verify_parents to check for extra parents tests: eliminate unnecessary setup test assertions
2011-05-06tests: check git does not barf on merge.ff values for future versions of gitJonathan Nieder
Maybe some day in the future we will want to support a syntax like [merge] ff = branch1 ff = branch2 ff = branch3 in addition to the currently permitted "true", "false", and "only" values. So make sure we continue to treat such configurations as though an unknown variable had been defined rather than erroring out, until it is time to implement such a thing, so configuration files using such a facility can be shared between present and future git. While at it, add a few missing && and start the "combining --squash and --no-ff" test with a known state so we can be sure it does not succeed or fail for the wrong reason. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2011-05-06tests: teach verify_parents to check for extra parentsJonathan Nieder
Currently verify_parents only makes sure that the earlier parents of HEAD match the commits given, and does not care if there are more parents. This makes it harder than one would like to check that, for example, parent reduction works correctly when making an octopus. Fix it by checking that HEAD^(n+1) is not a valid commit name. Noticed while working on a new test that was supposed to create a fast-forward one commit ahead but actually created a merge. Reported-by: Junio C Hamano <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2011-05-06merge: introduce merge.ff configuration variableJunio C Hamano
This variable gives the default setting for --ff, --no-ff or --ff-only options of "git merge" command. Signed-off-by: Junio C Hamano <>
2011-05-06Merge branch 'jc/maint-branch-mergeoptions' into mg/merge-ff-configJunio C Hamano
* jc/maint-branch-mergeoptions: merge: make branch.<name>.mergeoptions correctly override merge.<option>
2011-05-06merge: make branch.<name>.mergeoptions correctly override merge.<option>Junio C Hamano
The parsing of the additional command line parameters supplied to the branch.<name>.mergeoptions configuration variable was implemented at the wrong stage. If any merge-related variable came after we read branch.<name>.mergeoptions, the earlier value was overwritten. We should first read all the merge.* configuration, override them by reading from branch.<name>.mergeoptions and then finally read from the command line. This patch should fix it, even though I now strongly suspect that branch.<name>.mergeoptions that gives a single command line that needs to be parsed was likely to be an ill-conceived idea to begin with. Sigh... Helped-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2011-05-06tests: eliminate unnecessary setup test assertionsJonathan Nieder
Most of git's tests write files and define shell functions and variables that will last throughout a test script at the top of the script, before all test assertions: . ./ VAR='some value' export VAR >empty fn () { do something } test_expect_success 'setup' ' ... nontrivial commands go here ... ' Two scripts use a different style with this kind of trivial code enclosed by a test assertion; fix them. The usual style is easier to read since there is less indentation to keep track of and no need to worry about nested quotes; and on the other hand, because the commands in question are trivial, it should not make the test suite any worse at catching future bugs in git. While at it, make some other small tweaks: - spell function definitions with a space before () for consistency with other scripts; - use the self-contained command "git mktree </dev/null" in preference to "git write-tree" which looks at the index when writing an empty tree. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2011-04-14i18n: use test_i18n{cmp,grep} in t7600, t7607, t7611 and t7811Junio C Hamano
Signed-off-by: Junio C Hamano <>
2011-03-10i18n: git-merge "Wonderful" messageÆvar Arnfjörð Bjarmason
Gettextize the "Wonderful" message. A test in explicitly checked for this message. Change it to skip under GETTEXT_POISON=YesPlease. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2010-10-22merge -h: show usage even with corrupt indexNguyễn Thái Ngọc Duy
Part of a campaign to make sure "git <command> -h" works correctly when run from distractingly bad repositories. [jn: with rewritten log message and tests] Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-08-18t7600 (merge): test merge from branch yet to be bornJonathan Nieder
Some people like to "git fetch origin && merge origin/master" from the unborn branch provided when first initializing a repository. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>