summaryrefslogtreecommitdiff
path: root/t/t3425-rebase-topology-merges.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-09-07tests: stop testing `git rebase --preserve-merges`Libravatar Johannes Schindelin1-151/+0
This backend has been deprecated in favor of `git rebase --rebase-merges`. In preparation for dropping it, let's remove all the regression tests that would need it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16rebase: rename the two primary rebase backendsLibravatar Elijah Newren1-4/+4
Two related changes, with separate rationale for each: Rename the 'interactive' backend to 'merge' because: * 'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default. * 'interactive' is not the underlying strategy; merging is. * the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge. Rename the 'am' backend to 'apply' because: * Few users are familiar with git-am as a reference point. * Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems. * Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing. * While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too. * The directory where state is stored has never been called .git/rebase-am, it was always called .git/rebase-apply. For all the reasons listed above: * Modify the documentation to refer to the backends with the new names * Provide a brief note in the documentation connecting the new names to the old names in case users run across the old names anywhere (e.g. in old release notes or older versions of the documentation) * Change the (new) --am command line flag to --apply * Rename some enums, variables, and functions to reinforce the new backend names for us as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16rebase tests: mark tests specific to the am-backend with --amLibravatar Elijah Newren1-4/+4
We have many rebase tests in the testsuite, and often the same test is repeated multiple times just testing different backends. For those tests that were specifically trying to test the am backend, add the --am flag. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-28rebase: define linearization ordering and enforce itLibravatar Elijah Newren1-9/+6
Ever since commit 3f213981e44a ("add tests for rebasing merged history", 2013-06-06), t3425 has had tests which included the rebasing of merged history and whose order of applied commits was checked. Unfortunately, the tests expected different behavior depending on which backend was in use. Implementing these checks was the following four lines (including the TODO message) which were repeated verbatim three times in t3425: #TODO: make order consistent across all flavors of rebase test_run_rebase success 'e n o' '' test_run_rebase success 'e n o' -m test_run_rebase success 'n o e' -i As part of the effort to reduce differences between the rebase backends so that users get more uniform behavior, let's define the correct behavior and modify the different backends so they all get the right answer. It turns out that the difference in behavior here is entirely due to topological sorting; since some backends require topological sorting (particularly when --rebase-merges is specified), require it for all modes. Modify the am and merge backends to implement this. Performance Considerations: I was unable to measure any appreciable performance difference with this change. Trying to control the run-to-run variation was difficult; I eventually found a headless beefy box that I could ssh into, which seemed to help. Using git.git, I ran the following testcase: $ git reset --hard v2.20.0-rc1~2 $ time git rebase --quiet v2.20.0-rc0~16 I first ran once to warm any disk caches, then ran five subsequent runs and recorded the times of those five. I observed the following results for the average time: Before this change: "real" timing: 1.340s (standard deviation: 0.040s) "user" timing: 1.050s (standard deviation: 0.041s) "sys" timing: 0.270s (standard deviation: 0.011s) After this change: "real" timing: 1.327s (standard deviation: 0.065s) "user" timing: 1.031s (standard deviation: 0.061s) "sys" timing: 0.280s (standard deviation: 0.014s) Measurements aside, I would expect the timing for walking revisions to be dwarfed by the work involved in creating and applying patches, so this isn't too surprising. Further, while somewhat counter-intuitive, it is possible that turning on topological sorting is actually a performance improvement: by way of comparison, turning on --topo-order made fast-export faster (see https://public-inbox.org/git/20090211135640.GA19600@coredump.intra.peff.net/). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02tests: optionally skip `git rebase -p` testsLibravatar Johannes Schindelin1-0/+5
The `--preserve-merges` mode of the `rebase` command is slated to be deprecated soon, as the more powerful `--rebase-merges` mode is available now, and the latter was designed with the express intent to address the shortcomings of `--preserve-merges`' design (e.g. the inability to reorder commits in an interactive rebase). As such, we will eventually even remove the `--preserve-merges` support, and along with it, its tests. In preparation for this, and also to allow the Windows phase of our automated tests to save some well-needed time when running the test suite, this commit introduces a new prerequisite REBASE_P, which can be forced to being unmet by setting the environment variable `GIT_TEST_SKIP_REBASE_P` to any non-empty string. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix trivial &&-chain breakageLibravatar Jeff King1-2/+2
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>
2013-06-18rebase topology tests: fix commit names on case-insensitive file systemsLibravatar Johannes Sixt1-8/+8
The recently introduced tests used uppercase letters to denote cherry-picks of commits having the corresponding lowercase letter names. The helper functions also set up tags with the names of the commits. But this constellation fails on case-insensitive file systems because there cannot be distinct tags with names that differ only in case. Use a less subtle convention for the names of cherry-picked commits. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07add tests for rebasing merged historyLibravatar Martin von Zweigbergk1-0/+258
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>