blender
/
blender
136
404
Fork 586
Code Issues 6.2k Pull Requests 761 Projects 19 Wiki Activity

Re-design of submodules used in blender.git #104753

Closed
Sergey Sharybin wants to merge 2 commits from Sergey:submodules_refactor into main
pull from: Sergey:submodules_refactor
merge into: blender:main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Conversation 1 Commits 2 Files Changed 567 +2030073 -133

2 Commits

Author SHA1 Message Date
Sergey Sharybin bd8c1ebc05 Re-design of submodules used in blender.git 
See #104573 for the full explanation.

Brief summary is:

- `addons` and `addons_contrib` are now expected to be a checkout of
  corresponding repositories inside of top-level `scripts` folder.

- `scripts` are moved from `release/scripts` to the top level.

- Developer tools and locales are embedded to the main repository,
 2023-02-14 18:27:52 +01:00
Sergey Sharybin ec05e82b5c make_update: Support upstream remote workflow and update for subodules redesign 
There are two aspects of the change which is a bit hard to decouple one
from another.

One part of it is to move away from submodules, as per #104573.

The change ensures that the blender-addons and blender-addons-contrib
repositories are cloned under scripts/addons and scripts/addons_contrib
respectively.

If there were configure d submodules for those repositories they are
copied over to the new location, and nothing else happens. If an upstream
workflow is desired it is to be configured manually. This ensures that
the local work is preserved as good as possible.

If there are no submodules configured then a new checkout will be done,
following the remote organization from the main repository: if there is
remote called "upstream" in the main repository, the same semantic will
be used for addons and addons_contrib.

NOTE: The submodules are never deinitialized in the local checkout, this
is to be done manually after ensuring there is no work which can be lost.

The other part of the change is to support workflow when "origin" points
to a fork, and "upstream" points to the upstream repository. This is rather
common workflow in all sort of forges like Github, Gitlab, perhaps even
Gitea. Having better support of our tools for it seems to have string
benefits.

The idea of this change is to make it so `make update` will perform the
steps needed to update the branch of the fork to the upstream version.

This includes:
- Fetch the `upstream` remote
- `git merge --ff-only upstream/branch` if the current branch exists in
  the upstream.
- If the branch does not exist in the upstream, then it will be pulled
  from the `origin` instead (the behavior prior to this change).

The same logic is implemented for the addons and addons_contrib.

The `make update` will also check for the forked addons and addons-contrib
within the same user/organization as the blender.git fork and add the
"origin" to the checkout of addons when such a fork is detected. This allows
to fork the addons repository after the `make update` has been run for the
first time.
 2023-02-14 18:27:51 +01:00