⚠️ Repo-wide changes in 0.3.2 ⚠️

[pillo79]

Since cores are now automatically generated by CI, in release 0.3.2 we cleaned up the Git history of the repo by removing all references to old build files in the variants and firmwares folders (as the last step of #102). We pushed the new, slimmed down commits to the more traditional main branch.

All future work will now take place on the main branch. PRs that target arduino will not be accepted anymore and will have to be rebased on main. No further work will be done on the arduino branch and it will be removed in the short future.

😵‍💫 So what should I do..?

• If you are just getting started and downloaded this repo after release 0.3.2, there is nothing special you have to do. Just start your work from main as you normally would. 🚀

• If you downloaded a copy of the repository in the past, but never created any commit yourself, it's also really easy. Simply do a git fetch to download the latest updates, then checkout the main branch and continue using that. 🚀

• If you have local branches or commits that you want to keep up-to-date, and/or have submitted a PR that is still open, please read on. 🔧

🔧 How to fix your existing branches

Note

There are many ways to fix this with Git. The following describes the cherry-pick solution, but of course interactive rebase is OK too - just read the section below for what to expect when trying such a tricky operation.
The following also assumes:

• you have a branch named feature which was based off the arduino branch
• the origin remote refers to this repository.

To migrate a branch called feature on the new main:

1. Make sure you have downloaded the latest version of the main branch from this repository:

   git fetch origin

2. Take note of the checksums for your old commits on the feature branch.

   Run the following command, and it will show all commits in the feature branch, starting from the most recent one:

   git log feature

   The first ones (near the tip) will be yours, then the log will show other commits that were on the arduino branch at the moment you created your own. Copy the 40-char commit IDs of your commits to a temporary text file. Make sure to list them in the same order they are shown!

3. Create a new feature-on-main branch

   git checkout -b feature-on-main origin/main

   will create a new branch called feature-on-main from the latest commit on main, initially with no commits. Note the origin/ part - we need to start from the latest main, not old local copies you may have.

4. Re-apply the commits in this new branch.

   Walk the list you created in reverse order, so the oldest is used first (very important!), and apply each commit in your new branch:

   git cherry-pick <commit-id>

   All those commands should complete with no errors. When every commit has been applied, you will have a brand-new branch to continue your development from. If this was a PR, please open a separate PR and link the old one.

---

⚠️ HELP! I got conflicts during the cherry-pick operation

This means that something was changed since the time you created your branch. You need to review the files with the conflicts and fix the changes highlighted by <<<<< and >>>>>, before committing them. Read more on that here, for example.

Note that if your branch modified the files that have been removed (like old rebuilds did), you should remove them, not add them again. 😉

---

🧯 HELP! I did a rebase, pull, or something... and now everything is on fire 🔥

Usually Git is very good at detecting and ignoring duplicate commits. However in this case those in arduino appear different from the new main, since no binaries are ever mentioned in the latter. So, Git probably tried to apply some from the old ones from the arduino branch over the tip of main, creating LOTS of conflicts.

All automatic operations like those(*) will certainly fail, and will create mangled history should they complete somehow.

↩️ Abort the current operation. This is usually done adding --abort to the command you tried. If all else fails, try a git reset --hard to your original branch name.

(*) The only somewhat safe operation is an interactive rebase where you manually edit and remove all duplicate commits that Git would wrongly apply.

[KurtE]

Questions:

What does that do to the current existing Pull requests?

When you say local copy, Are you suggesting that we need to delete our forks and re-fork?

Thanks

Edit: Note: My current stuff was only maybe a week or so out of date. Updated to the previous time when the underlying
zephyr just before the current zephyr release... So far what I have done appears to be working:
a) Update my fork/branch (arduino) to be in sync with master Arduino fork: git reset --hard upstream/arduino
b) Checked to see if any more variants were deleted, like the old GIGA went to the more decorated name earlier.
c) (activate venv) and west update
d) ./extras/build_all.sh
And all of the builds completed.

[pillo79]

Thanks for the feedback @KurtE, obviously there's no 0.3.2 yet - this was all in preparation to the big force push. However we've discussed solutions to your questions and come up with an alternative proposal which we will implement shortly. I will also update this issue with the new instructions. Stay tuned :-)