Backmerge upstream

[carletex]

What I had to do:

1. Sync branch upstream-main branch with SE-2 (in the GitHub UI... but you can also add the remote locally and do it locally)
2. Pull upstream-main locally
3. Create backmerge-upstream branch from the main branch
4. Merge upstream-main => backmerge-upstream
5. Fix conflicts

• This will be particular for every case, maybe we should document it (if it's not already). In this case I had to "accept yours" in the root package.json file and add the next:serve manually into the template/base package.json.
  6 Run yarn add changeset to create the changeset file (selectect "patch")

7. Create PR. Since this is a fork, it automatically points to the SE-2 repo, so I have to manually change it (not sure if there is a way to default to this repo, even if it's a fork).

Some of this can be used to update the Contributing guide #4

---

I think we need to merge this (without squash) to keep the commits from SE-2 (if not we'll encounter weird conflicts).

If we merge:

• A PR will be automatically created. e.g. Version Packages #5
• When that PR is merged, the NPM package will be published
• If we don't want to merge, we can still keep PRing other PRs into main (with changeset) and the "version packages" PR will update automagically.

[carletex]

Open to new workflows if you all can think of something better. This one is not simple, but it works for now :D

[rin-st]

Lgtm!

Create PR. Since this is a fork, it automatically points to the SE-2 repo, so I have to manually change it (not sure if there is a way to default to this repo, even if it's a fork).

As I understand if you're forked repo, there is no way to change default to this repo. I think good way is to just duplicate the repo. It allows to do everything you mentioned, but it won't point to se-2 repo since it's not a fork.

Example of duplicated repo.

Since there's already changes in this repo (create-eth), probably it's worth

1. To synchronize it with se-2
2. Rename it to some "new-repo-name"
3. Create new repo "create-eth"
4. Duplicate "new-repo-name" to "create-eth"

or smth like that. Maybe 2. duplicate to "new-repo-name" 3. Duplicate "new-repo-name" to "create-eth"

But keep in mind that issues/prs are not copied, so it need to be stored somewhere before copying

[carletex]

. I think good way is to just duplicate the repo.

This might be a good idea @rin-st

I guess the only thing that we'll lose is the UI sync?

Which I guess is ok, we can do it on our computer (we can add the SE-2 core as remote and sync from there)

And I guess if someday we want to sync the other way around (create-eth => se-2) having a fork is handy.

Let's hear what @technophile-04 thinks too!

[technophile-04]

7. Create PR. Since this is a fork, it automatically points to the SE-2 repo, so I have to manually change it (not sure if there is a way to default to this repo, even if it's a fork).

I think maybe for now we can keep it as it is (forked)

Researching for a bit there is no way to configure default PR branch in github :(

According to this comment, having fork under organization marks default PR branch as organization forked repo but its not true I just tried it on Buidlguidl/scaffold-base just to be double sure and it doesn't work.

To workaround this if you create a PR through gh cli, as mentioned here with git create pr —base main

Maybe we can add a point in #4 regarding this, that make sure you select the base repo as this while creating PR

But, yeah I feel for now we could keep it as forked and if it gets really PITA in future we could raise a ticket to github so that they can detach our fork as mentioned here

5. Fix conflicts

    This will be particular for every case, maybe we should document it (if it's not already). In this case I had to "accept yours" in the root package.json file and add the next:serve manually into the template/base package.json.

Yup, we have just mentioned to resolve merge conflicts here but maybe we could add a sub point their regarding this case (since it’s very common and will also direct people how to resolve this case nicely), will add it to #4

Side quest:

Particular to root package.json merge conflicts(where almost want to do “accept ours”) there seems ours a flag in git which can be passed to automate this.

Not sure if we can do configure this flag for a particular file on merging more discussion here

Lol not sure if we should have this by default, but wanted to share 🙌

1. Sync branch upstream-main branch with SE-2 (in the GitHub UI... but you can also add the remote locally and do it locally)

Side quest

We don’t need this at all, and clicking synch button on GH UI is good,

But was just curious how people are handling this stuff and stumbled upon :

https://github.com/wei/pull

https://stackoverflow.com/questions/23793062/can-forks-be-synced-automatically-in-github

—-

but this is looking great, Thanks Carlos! And Rinat for suggestions, Merging this 🙌