[Discuss] Merge `main` into `relax` instead of doing rebase

[kparzysz-quic]

There are several issues with doing rebases:

1. Rebase rewrites all commits in the rebased branch.
2. Rebases cannot be done incrementally (they actually grow with time).

We're planning to integrate Relax into our ongoing development, which would entail frequently including new "relax" commits (without waiting for the "official" relax-TVM synchronization. If the "relax" branch continues to be rebased on top of "main", the point (1) above would make it somewhat painful for us to stay up-to-date with it.

We have a similar situation with our downstream development branch and the upstream "main". What we do is that we merge (git merge) the upstream "main" branch into our downstream branch on an essentially daily basis. The benefits of doing that are:

1. All commit SHAs are preserved: git pull works before and after a merge.
2. Merges can be done incrementally (if there is only 1 new commit in "main", the merge will bring only 1 new commit). Likelihood of conflicts decreases significantly.

We'd like to propose that similar process is done for synchronizing the "relax" branch with the "main" branch. Downstream consumers (like us) could merge both "main" and "relax" into their development branches, and these merges would coexist seamlessly.

[TejashShah]

cc @YuchenJin @jwfromm

[slyubomirsky]

It's worth considering how much we value having a linear commit history. One possibility (if we really love having a linear commit history) could be to use merging while this repo is a separate fork and later rewrite history only once when (I hope) Relax is merged into mainline TVM, rather than doing rebases every so often.

[slyubomirsky]

Points from the Jan. 24 Relax open developer meeting:

• One possibility is to build up a script that specifies how to do the rebase and make it easier to build on top of past rebases, which would address the problem of rebases not being incremental. The basis of this approach would be git rebase [old base branch] --onto [upstream]/[new base branch]
• Keeping the history linear is nice and made a lot of sense when we expected Relax to be merged into mainline TVM very soon, but now that it is taking longer to get Relax merged into mainline TVM, it might be preferable to avoid losing so much time to doing rebases
• We could try potentially grabbing only the new commits from upstream that we need rather than doing complete rebases
• Question: If we use merging for some time and we want to turn the history linear via a rebase, how hard would it be?
  • Potentially no harder than a rebase is anyway, so it won’t make life harder if we do choose to use merging and linearize later. git rerere (reuse recorded resolutions) can be used to save conflict resolutions: https://git-scm.com/book/en/v2/Git-Tools-Rerere
  • Maybe it’s not important to linearize the history, since an eventual merging of Relax into mainline would be done via PRs that are going to squash away the history anyway

We did not come to a conclusion at the meeting and will continue to discuss this subject.

[driazati]

I missed the meeting but I believe merging makes a lot of sense here, especially since it works out of the box without us having to build anything to hack on top of git or add any non-standard tooling (e.g. the script described above). With the octoml/relax in the picture as well we would be rebasing on top of rebases which makes github a little upset.

[slyubomirsky]

@driazati Continued discussion of this issue is on the agenda for tomorrow's discussion; you're welcome to attend

[slyubomirsky]

Notes from the continued discussion of this issue in the Jan. 31, 2023, open development meeting:

• Rebasing is very demanding on the person doing it, so merging could be very beneficial. On the other hand, a linear history is helpful for managing the repo. Worth trying to do an experiment
• Proposal from Tianqi: For foundational work on Unity, we should try to keep the history linear. We could switch to merging later
• Clarification: By “foundational work,” we are referring to initially setting up the unity branch on apache/tvm
• Unlikely to have lots of conflicts in merges if we stick to having feature branches
• Qualcomm has been using merges for their development branch, for merging main into development. They use rebase/squash and merge for handling PRs. This is a reasonable workflow because it does not require rewriting history and there are no split points in the repo; it does not break ongoing PRs. Additionally, git pull works without issue. So far have not encountered huge issues from having merge commits in their history
• We can try this merging discipline for the unity branch (see https://github.com/apache/tvm/issues/13876)
• What would a merging experiment look like?
• We can make a fork, use merges, and see if we can linearize it afterwards
• Why is it important to linearize afterwards?
  • It’s good to have, though not absolutely necessary
  • Would be good to know if it’s not possible or very difficult
  • In principle, you would expect it to be about as difficult as a rebase from scratch
• Benefits of merging: No rewriting history, conflict resolution is documented

Meeting consensus: Strong majority in favor of trying an experiment. We will set up a fork and try merging from main, report back on any issues, and discuss whether we should do it in the unity branch after the initial establishment

[supersat]

If we tag all relax commits with [Relax], could we filter the commits to get a simple relax-only linear timeline?

[kparzysz-quic]

If we tag all relax commits with [Relax], could we filter the commits to get a simple relax-only linear timeline?

If we maintain linear order within the relax/unity branch, then yes.