Main and Dev branches have diverged

[pradeeban]

As a best practice, commit your changes to dev branch. Then, bulk-commit from the dev branch to main branch.
If we have experimental features, we could also introduce a new "experimental" branch.

Right now, it is not possible to merge dev branch into main branch (or vice versa), since they have diverged.

This needs to be fixed. (At any times, main branch should not have commits that are not in the "bleeding edge" dev branch).

Commit to dev first and then commit to main.
Alternatively, commit to a feature-branch and then merge that feature-branch to main and dev.

[01bps]

Sure, I’ll keep this in mind going forward to ensure a smoother workflow.

I know this will be a bit challenging, but I’d like to take it up. I’ll first test things locally and work through the conflicts to stabilise both branches. I can see how this has created a roadblock.

Let me know if you have any specific expectations before I begin!

[pradeeban]

In the initial implementation of Beehive, @mdxabu implemented everything in main since it was only his work as part of the Alaskan Season of Code.

But when we got more useful and excellent commits from @ishaanxgupta and @01bps and continuous development from @mdxabu, the contributions diverged.

@mdxabu and @01bps commits went to main and @ishaanxgupta's commits went to dev.

One ideal solution is bring all the commits from main to dev, so that there is no commit in main branch that is not in the dev branch. Once that has happened, we all should commit to just dev - especially during the GSoC application period.

Then eventually, we could merge the dev back into main (and continue the development again in dev... continuing the iteration). Some sort of formal way in Git management.

@01bps do you think you could make your and @mdxabu's commits into dev branch, resolving the merge conflict we currently have in dev --> main?

That is going to be a one-big pull request from main --> dev with resolved merge conflicts in dev.

Just to clarify, this will be a pull request to dev.

After this is done, we should probably freeze the main branch (and follow the commit workflow discussed above for commits to main).

[ishaanxgupta]

In the initial implementation of Beehive, @mdxabu implemented everything in main since it was only his work as part of the Alaskan Season of Code.

But when we got more useful and excellent commits from @ishaanxgupta and @01bps and continuous development from @mdxabu, the contributions diverged.

@mdxabu and @01bps commits went to main and @ishaanxgupta's commits went to dev.

One ideal solution is bring all the commits from main to dev, so that there is no commit in main branch that is not in the dev branch. Once that has happened, we all should commit to just dev - especially during the GSoC application period.

Then eventually, we could merge the dev back into main (and continue the development again in dev... continuing the iteration). Some sort of formal way in Git management.

@01bps do you think you could make your and @mdxabu's commits into dev branch, resolving the merge conflict we currently have in dev --> main?

That is going to be a one-big pull request from main --> dev with resolved merge conflicts in dev.

Just to clarify, this will be a pull request to dev.

After this is done, we should probably freeze the main branch (and follow the commit workflow discussed above for commits to main).

Yes, this is a good idea so that we know where our main branch stands, and we work on the dev branch during GSOC. Also, the idea of an experimental branch is good for experimenting with features out of the box.

[01bps]

In the initial implementation of Beehive, @mdxabu implemented everything in main since it was only his work as part of the Alaskan Season of Code.

But when we got more useful and excellent commits from @ishaanxgupta and @01bps and continuous development from @mdxabu, the contributions diverged.

@mdxabu and @01bps commits went to main and @ishaanxgupta's commits went to dev.

One ideal solution is bring all the commits from main to dev, so that there is no commit in main branch that is not in the dev branch. Once that has happened, we all should commit to just dev - especially during the GSoC application period.

Then eventually, we could merge the dev back into main (and continue the development again in dev... continuing the iteration). Some sort of formal way in Git management.

@01bps do you think you could make your and @mdxabu's commits into dev branch, resolving the merge conflict we currently have in dev --> main?

That is going to be a one-big pull request from main --> dev with resolved merge conflicts in dev.

Just to clarify, this will be a pull request to dev.

After this is done, we should probably freeze the main branch (and follow the commit workflow discussed above for commits to main).

Thanks for the detailed explanation!

Here’s my plan aligning with your suggestion and make sure we’re on the same page:

I'll first merge main into dev locally to bring in all missing commits from me and @mdxabu. Then, I'll resolve all merge conflicts in dev and ensure everything is stable. Once that’s done, I’ll open a PR from this local dev to upstream dev.

Once this PR is merged, dev will be fully up to date with main, and moving forward, all work can continue in dev. After this, we can safely merge dev back into main and freeze it.

Let me know if this approach looks good, and I’ll get started!

[pradeeban]

Sounds perfect to me. Great team work!

[pradeeban]

@01bps fixed it. Thanks, @01bps.

Let's get all the commits to dev branch from now on, @01bps @mdxabu and keep the main frozen while we have this active period. Feel free to create feature-branches as needed, in addition to dev.