summaryrefslogtreecommitdiff
path: root/t/t3033-merge-toplevel.sh
AgeCommit message (Collapse)AuthorFilesLines
2015-04-29merge: handle FETCH_HEAD internallyLibravatar Junio C Hamano1-5/+5
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 <gitster@pobox.com>
2015-04-29merge: test the top-level merge driverLibravatar Junio C Hamano1-0/+136
We seem to have tests for specific merge strategy backends (e.g. recursive), but not much test coverage for the "git merge" itself. As I am planning to update the semantics of merging "FETCH_HEAD" in such a way that these two git pull . topic_a topic_b... vs. git fetch . topic_a topic_b... git merge FETCH_HEAD are truly equivalent, let me add a few test cases to cover the tricky ones. Signed-off-by: Junio C Hamano <gitster@pobox.com>