summaryrefslogtreecommitdiff
path: root/t/t7600-merge.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-02-16merge: allow fast-forward when merging a tracked tagLibravatar Junio C Hamano1-1/+37
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 <gitster@pobox.com>
2017-10-07tests: fix diff order arguments in test_cmpLibravatar Stefan Beller1-3/+3
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 <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-23merge: save merge state earlierLibravatar Michael J Gruber1-0/+15
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 <hippy2981@gmail.com> Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-14merge: ensure '--abort' option takes no argumentsLibravatar Chris Packham1-0/+2
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 <judge.packham@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-14merge: add '--continue' option as a synonym for 'git commit'Libravatar Chris Packham1-0/+9
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 <judge.packham@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-06Merge branch 'jv/merge-nothing-into-void'Libravatar Junio C Hamano1-0/+10
"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'Libravatar Junio C Hamano1-0/+28
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 voidLibravatar Junio C Hamano1-0/+10
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 <gitster@pobox.com>
2016-03-21commit: do not lose SQUASH_MSG contentsLibravatar Sven Strickroth1-0/+28
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 <gitster@pobox.com>. Signed-off-by: Sven Strickroth <sven@cs-ware.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-30Merge branch 'jk/merge-file-exit-code'Libravatar Junio C Hamano1-0/+33
"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 127Libravatar Jeff King1-0/+33
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix trivial &&-chain breakageLibravatar Jeff King1-1/+1
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-15git-show: fix 'git show -s' to not add extra terminator after merge commitLibravatar Max Kirillov1-6/+5
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 t4013-diff-various.sh 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 t7007-show.sh 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 <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-23t7600: fix typo in test titleLibravatar Junio C Hamano1-1/+1
Spotted by Ram, confirmed by Miklos. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-02merge: handle --ff/--no-ff/--ff-only as a tri-state optionLibravatar Miklos Vajna1-3/+9
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 <vmiklos@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26Merge branch 'vl/typofix'Libravatar Junio C Hamano1-1/+1
* vl/typofix: random typofixes (committed missing a 't', successful missing an 's')
2013-06-19random typofixes (committed missing a 't', successful missing an 's')Libravatar Veres Lajos1-1/+1
Signed-off-by: Veres Lajos <vlajos@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25t7600: use test_config to set/unset git config variablesLibravatar Yann Droneaud1-34/+26
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 <ydroneaud@opteya.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Fix tests under GETTEXT_POISON on parseoptLibravatar Jiang Xin1-1/+1
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 <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-09merge: do not launch an editor on "--no-edit $tag"Libravatar Junio C Hamano1-0/+12
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 <gitster@pobox.com>
2012-02-05merge: do not create a signed tag merge under --ff-only optionLibravatar Junio C Hamano1-0/+13
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 <gitster@pobox.com>
2011-11-08merge: record tag objects without peeling in MERGE_HEADLibravatar Junio C Hamano1-1/+5
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 <gitster@pobox.com>
2011-11-07merge: notice local merging of tags and keep it unwrappedLibravatar Junio C Hamano1-3/+3
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 <gitster@pobox.com>
2011-10-12Teach merge the '[-e|--edit]' optionLibravatar Jay Soffian1-0/+23
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 <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-16Merge branch 'mg/merge-ff-config'Libravatar Junio C Hamano1-6/+58
* 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/t7600-merge.sh
2011-05-11Merge branch 'jc/maint-branch-mergeoptions'Libravatar Junio C Hamano1-0/+32
* 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'Libravatar Junio C Hamano1-74/+73
* 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 gitLibravatar Jonathan Nieder1-2/+14
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 <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-06tests: teach verify_parents to check for extra parentsLibravatar Jonathan Nieder1-0/+1
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 <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-06merge: introduce merge.ff configuration variableLibravatar Junio C Hamano1-2/+41
This variable gives the default setting for --ff, --no-ff or --ff-only options of "git merge" command. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-06Merge branch 'jc/maint-branch-mergeoptions' into mg/merge-ff-configLibravatar Junio C Hamano1-0/+33
* jc/maint-branch-mergeoptions: merge: make branch.<name>.mergeoptions correctly override merge.<option>
2011-05-06merge: make branch.<name>.mergeoptions correctly override merge.<option>Libravatar Junio C Hamano1-0/+32
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 <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-06tests: eliminate unnecessary setup test assertionsLibravatar Jonathan Nieder1-74/+72
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: . ./test-lib.sh 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 <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-14i18n: use test_i18n{cmp,grep} in t7600, t7607, t7611 and t7811Libravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-merge "Wonderful" messageLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Gettextize the "Wonderful" message. A test in t7600-merge.sh explicitly checked for this message. Change it to skip under GETTEXT_POISON=YesPlease. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-22merge -h: show usage even with corrupt indexLibravatar Nguyễn Thái Ngọc Duy1-0/+11
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 <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18t7600 (merge): test merge from branch yet to be bornLibravatar Jonathan Nieder1-0/+21
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 <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18t7600 (merge): check reflog entryLibravatar Jonathan Nieder1-1/+7
The details of the reflog message are not important, but including something sane in the reflog is. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18t7600 (merge): do not launch gitk for --debugLibravatar Jonathan Nieder1-29/+29
Probably as a development aid, this test script runs gitk --all to allow the driver to inspect history between tests when run with --debug. As a result, running all tests with --debug requires closing a long series of gitk displays, one at a time. Use git log --graph --oneline instead. This way, the history is available for viewing with "git show" but the test script finishes without interaction. Longer term, it would be nice to have an option to run a user-specified command between tests. This patch does not do that. Cc: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18t7600 (merge): modernize styleLibravatar Jonathan Nieder1-187/+101
Guard setup commands with test_expect_success, so they are easier to visually skip over and get to the good part. While at it: - use "printf '%s\n' a b ..." instead of "cat <<EOF" for test vectors with short lines; - use test_cmp instead of test foo = bar where possible, for better output with -v on failure; - do not go to extraordinary lengths to print a relevant message when test commands fail. There is a patch in flight that could be used to restore the nice error messages in a cleaner way. Cc: Lars Hjemli <hjemli@gmail.com> Cc: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18merge: do not mistake (ancestor of) tag for branchLibravatar Jonathan Nieder1-4/+12
If no branch 'foo' exists but a tag 'foo' does, then git merge foo^ results in Merge branch 'foo' (early part) as a commit message, because the relevant code path checks that refs/heads/foo is a valid refname for writing rather than for reading. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-06war on "sleep" in testsLibravatar Junio C Hamano1-2/+1
In many places in test suite we have "sleep"s that do not have to be there. - I do not simply see the point of the one in t3500. It may be making sure that the timestamp order of commits generated during the test is stable, in which case test_tick is the right ingredient to use without wasting tester's time. - The one in t4011 is to make sure that the plumbing diff-index notices the stat-dirtyness of a removed then identically recreated symlink. Keeping the old symlink around to make sure that a newly created symlink gets different ino would be sufficient for that purpose. - The one in t7600 is to make sure that "git merge" does not get confused by stat-dirty "file" in the working tree. Again, keeping the old file around and creating an identical copy to ensure a different ino would be sufficient for that purpose. The "racy git" tests in t0010 are inherently about mtime between the index itself and index entries. The "sleep" in that test must stay as they are. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-30Teach 'git merge' and 'git pull' the option --ff-onlyLibravatar Björn Gustavsson1-0/+41
For convenience in scripts and aliases, add the option --ff-only to only allow fast-forwards (and up-to-date, despite the name). Disallow combining --ff-only and --no-ff, since they flatly contradict each other. Allow all other options to be combined with --ff-only (i.e. do not add any code to handle them specially), including the following options: * --strategy (one or more): As long as the chosen merge strategy results in up-to-date or fast-forward, the command will succeed. * --squash: I cannot imagine why anyone would want to squash commits only if fast-forward is possible, but I also see no reason why it should not be allowed. * --message: The message will always be ignored, but I see no need to explicitly disallow providing a redundant message. Acknowledgements: I did look at Yuval Kogman's earlier patch (107768 in gmane), mainly as shortcut to find my way in the code, but I did not copy anything directly. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-19Merge branch 'mv/merge-noff'Libravatar Junio C Hamano1-0/+16
* mv/merge-noff: builtin-commit: use reduce_heads() only when appropriate Conflicts: builtin-commit.c t/t7600-merge.sh
2008-10-17Merge branch 'maint'Libravatar Junio C Hamano1-0/+24
* maint: t1301-shared-repo.sh: don't let a default ACL interfere with the test git-check-attr(1): add output and example sections xdiff-interface.c: strip newline (and cr) from line before pattern matching t4018-diff-funcname: demonstrate end of line funcname matching flaw t4018-diff-funcname: rework negated last expression test Typo "does not exists" when git remote update remote. remote.c: correct the check for a leading '/' in a remote name Add testcase to ensure merging an early part of a branch is done properly Conflicts: t/t7600-merge.sh
2008-10-14Add testcase to ensure merging an early part of a branch is done properlyLibravatar Miklos Vajna1-0/+26
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-03builtin-commit: use reduce_heads() only when appropriateLibravatar Miklos Vajna1-0/+16
Since commit 6bb6b034 (builtin-commit: use commit_tree(), 2008-09-10), builtin-commit performs a reduce_heads() unconditionally. However, it's not always needed, and in some cases even harmful. reduce_heads() is not needed for the initial commit or for an "ordinary" commit, because they don't have any or have only one parent, respectively. reduce_heads() must be avoided when 'git commit' is run after a 'git merge --no-ff --no-commit', otherwise it will turn the non-fast-forward merge into fast-forward. For the same reason, reduce_heads() must be avoided when amending such a merge commit. To resolve this issue, 'git merge' will write info about whether fast-forward is allowed or not to $GIT_DIR/MERGE_MODE. Based on this info, 'git commit' will only perform reduce_heads() when it's committing a merge and fast-forward is enabled. Also add test cases to ensure that non-fast-forward merges are committed and amended properly. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-03builtin-merge: refresh the index before calling a strategyLibravatar Miklos Vajna1-0/+9
In case a file is touched but has no real changes then we just have to update the index and should not error out. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-03Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Start 1.6.0.2 maintenance cycle tests: use "git xyzzy" form (t7200 - t9001) tests: use "git xyzzy" form (t7000 - t7199) Fix passwd(5) ref and reflect that commit doens't use commit-tree improve handling of sideband message display tests: use "git xyzzy" form (t3600 - t6999) tests: use "git xyzzy" form (t0000 - t3599) checkout: fix message when leaving detached HEAD clone: fix creation of explicitly named target directory 'git foo' program identifies itself without dash in die() messages setup_git_directory(): fix move to worktree toplevel directory update-index: fix worktree setup Start conforming code to "git subcmd" style read-tree: setup worktree if merge is required grep: fix worktree setup diff*: fix worktree setup Conflicts: RelNotes t/t3900-i18n-commit.sh t/t7003-filter-branch.sh
2008-09-03tests: use "git xyzzy" form (t7200 - t9001)Libravatar Nanako Shiraishi1-1/+1
Converts tests between t7201-t9001. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>