aboutsummaryrefslogtreecommitdiff
path: root/t/t6010-merge-base.sh
Commit message (Collapse)AuthorAge
* Merge branch 'jk/merge-base-fork-point-without-reflog'Junio C Hamano2016-10-26
|\ | | | | | | | | | | | | | | "git rebase" immediately after "git clone" failed to find the fork point from the upstream. * jk/merge-base-fork-point-without-reflog: merge-base: handle --fork-point without reflog
| * merge-base: handle --fork-point without reflogJeff King2016-10-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The --fork-point option looks in the reflog to try to find where a derived branch forked from a base branch. However, if the reflog for the base branch is totally empty (as it commonly is right after cloning, which does not write a reflog entry), then our for_each_reflog call will not find any entries, and we will come up with no merge base, even though there may be one with the current tip of the base. We can fix this by just adding the current tip to our list of collected entries. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | merge: refuse to create too cool a merge by defaultJunio C Hamano2016-03-23
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <gitster@pobox.com>
* Merge branch 'bm/merge-base-octopus-dedup'Junio C Hamano2014-01-10
|\ | | | | | | | | | | | | | | | | "git merge-base --octopus" used to leave cleaning up suboptimal result to the caller, but now it does the clean-up itself. * bm/merge-base-octopus-dedup: merge-base --octopus: reduce the result from get_octopus_merge_bases() merge-base: separate "--independent" codepath into its own helper
| * merge-base --octopus: reduce the result from get_octopus_merge_bases()Junio C Hamano2013-12-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Scripts that use "merge-base --octopus" could do the reducing themselves, but most of them are expected to want to get the reduced results without having to do any work themselves. Tests are taken from a message by Василий Макаров <einmalfel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> --- We might want to vet the existing callers of the underlying get_octopus_merge_bases() and find out if _all_ of them are doing anything extra (like deduping) because the machinery can return duplicate results. And if that is the case, then we may want to move the dedupling down the callchain instead of having it here.
* | merge-base: teach "--fork-point" modeJunio C Hamano2013-10-29
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "git pull --rebase" command computes the fork point of the branch being rebased using the reflog entries of the "base" branch (typically a remote-tracking branch) the branch's work was based on, in order to cope with the case in which the "base" branch has been rewound and rebuilt. For example, if the history looked like this: o---B1 / ---o---o---B2--o---o---o---Base \ B3 \ Derived where the current tip of the "base" branch is at Base, but earlier fetch observed that its tip used to be B3 and then B2 and then B1 before getting to the current commit, and the branch being rebased on top of the latest "base" is based on commit B3, it tries to find B3 by going through the output of "git rev-list --reflog base" (i.e. Base, B1, B2, B3) until it finds a commit that is an ancestor of the current tip "Derived". Internally, we have get_merge_bases_many() that can compute this with one-go. We would want a merge-base between Derived and a fictitious merge commit that would result by merging all the historical tips of "base". When such a commit exist, we should get a single result, which exactly match one of the reflog entries of "base". Teach "git merge-base" a new mode, "--fork-point", to compute exactly that. Helped-by: Martin von Zweigbergk <martinvonz@gmail.com> Helped-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tests: eliminate unnecessary setup test assertionsJonathan Nieder2011-05-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* tests: add missing &&Jonathan Nieder2010-11-09
| | | | | | | | | | | Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* merge-base --independent to print reduced parent list in a mergeJonathan Nieder2010-08-18
| | | | | | | | | | | | While show-branch --independent does not support more than MAX_REVS revs, git internally supports more with a different algorithm. Expose that functionality as "git merge-base --independent". This should help scripts to catch up with builtin merge in supporting dodecapus. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* merge-base --octopus to mimic show-branch --merge-baseJonathan Nieder2010-08-18
| | | | | | | | | | | | | While show-branch --merge-base does not support more than MAX_REVS revs, git supports more with a different algorithm (v1.6.0-rc0~51^2~13, Introduce get_octopus_merge_bases() in commit.c, 2008-06-27). Expose that functionality. This should help scripts to catch up with builtin merge in supporting dodecapus. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6010 (merge-base): modernize styleJonathan Nieder2010-08-18
| | | | | | | | | | | | | | | | Guard setup with test_expect_success, put the opening quote starting each test on the same line as the test_expect_* invocation, and combine related actions into single tests. While at it: - use test_cmp instead of expr or test $foo = $bar, for more helpful output with -v when tests fail; - use test_commit for brevity. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-merge-base/git-show-branch --merge-base: Documentation and testMichael J Gruber2009-08-05
| | | | | | | | | | | | Currently, the documentation suggests that 'git merge-base -a' and 'git show-branch --merge-base' are equivalent (in fact it claims that the former cannot handle more than two revs). Alas, the handling of more than two revs is very different. Document this by tests and correct the documentation to reflect this. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6010-merge-base.sh: Depict the octopus test graphMichael J Gruber2009-08-05
| | | | | | | ...so that it is easier to reuse it for other tests. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* merge-base-many: add trivial tests based on the documentationJunio C Hamano2008-07-29
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Don't use the 'export NAME=value' in the test scripts.Bryan Donlan2008-05-05
| | | | | | | | | | | | | | This form is not portable across all shells, so replace instances of: export FOO=bar with: FOO=bar export FOO Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Rewrite "git-frotz" to "git frotz"Junio C Hamano2007-07-02
| | | | | | This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cleanup merge-base test scriptSam Vilain2007-06-26
| | | | | | | Add a picture, and keep the setup and the tests together. Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Additional merge-base tests (revised)A Large Angry SCM2006-07-09
| | | | Signed-off-by: A Large Angry SCM <gitzilla@gmail.com>
* name-rev: do not omit leading components of ref name.Junio C Hamano2006-01-11
| | | | | | | | | | In a repository with mainto/1.0 (to keep maintaining the 1.0.X series) and fixo/1.0 (to keep fixes that apply to both 1.0.X series and upwards) branches, "git-name-rev mainto/1.0" answered just "1.0" making things ambiguous. Show refnames unambiguously like show-branch does. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Add test case for merge-base.Junio C Hamano2005-11-11
Although it was shown that the "full contamination" was not really full during the list discussion, the series improves things without incurring extra parsing cost, and here is a test to check that. Signed-off-by: Junio C Hamano <junkio@cox.net>