Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Merge conflicts in pull requests after "Megamove" #8232

Description

@matthew-brett

On Friday 12 June 2026, we merged a large commit:

In fact, the commit was so large, we're calling it the Megamove commit.

See below for more details.

The Megamove commit has important implications for pull requests (PRs) made before the Megamove commit. Call these Pre-Megamove PRs (PMPRs).

Because of the file reorganizations in Megamove, very few PMPRs will merge cleanly with the latest (post-Megamove) main branch in Scikit image.

If you have any questions about these changes, please ask us for help. @ mention @matthew-brett in the first instance (who is responsible for this outrage.

What to do if you have a Pre-Megamove PR (PMPR)

Please do not attempt to merge the scikit-image main branch into your PR. It will create merge conflicts that are difficult to resolve.

To avoid these post-Megamove merge conflicts, we have moved all PMPRs to target a new scikit-image branch called pre-megamove-integration, as the base-branch for the PR in Github.

That is - your PMPR used to have main as the base branch. It now has pre-megamove-integration as its base branch.

As its name suggests, pre-megamove-integration is basically the state of the scikit-image tree before Megamove. With this as the base branch, PR authors can interact with us and the Github interface as if Megamove had not happened. For example, you can click on the Github GUI "Update branch" button to merge in the latest changes from pre-megamove-integration (instead of main). Of course you can also do the same from the command line:

git fetch origin  # Or whatever your remote for scikit-image/scikit-image is called.
git merge origin/pre-megamove-integration

Remember - if you have a PMPR - do not merge origin/main (which is post-Megamove).

When we merge your PMPR, we merge into pre-megamove-integration. Every week or so, we (the maintainers) will take the new changes from pre-megamove-integration, and port them over to the new Megamove directory structure. We'll let you know when we've done this for your merged PMPR.

What to do if you're starting a new (post-Megamove) PR

If you are starting work on a new PR, please start with the standard main branch as the base-branch of your PR, and work with the post-Megamove directory structure. Read on for more detail on that structure, and how it differs from the pre-Megamove structure.

On the changes in Megamove

We're getting ready for the scikit-image 2 release. Scikit-image 2 will be in a whole new source tree, skimage2. However, it will differ only in part from current skimage (scikit-image 1, the scikit-image we all know and love). In getting ready for that change, we've moved all the remaining implementation code from src/skimage to src/_skimage2, and replaced the implementation code in src/skimage with shims, that import the actual implementation from src/_skimage2. Thus the implementation is now in src/_skimage2 and src/skimage now consists of shims, not the implementation code (with some very minor deviations from that rule).

Meanwhile, in Megamove we have copied the test suite wholesale, from tests/skimage to tests/skimage2.

As you've seen above, the Megamove will cause dramatic, unhelpful and potentially dangerous merge conflicts between PRs against origin/main prior to the megamove, because code changes in PRs up until now, will typically be in src/skimage, and these changes should - after mega move - go in the matching files in src/_skimage. Similarly, tests will typically be in tests/skimage, but these tests need to be copied across, and possibly adapted to new in Skimage2 behavior, in tests/skimage2.

The danger to you, if you have a PMPR, is when you try doing a merge of your PMPR with main. You'll get a big merge conflict, and that will be hard to resolve using the Github GUI or locally; the merge conflicts above will be sufficiently complex and error prone that, unless you really understand the Megamove changes, you are likely to find the merge confusing, and to make incorrect changes. We're not saying this to be condescending, this was our experience as well.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions