Oh, in case you updated your local 2.1 branch after main was merged onto it, but before I force-pushed to fix it, just reset your 2.1 branch by checking out your local 2.1 branch, doing `git remote update` and then `git reset --hard upstream/2.1` before you do anything else. That way, we don't get those commits added back in accidentally.
On Thu, Dec 1, 2022 at 5:26 PM Christopher <ctubb...@apache.org> wrote: > > Hi Accumulo devs, > > I just wanted to give you a heads up about branch maintenance for the > 2.1 branch. A few mistakes were made, and the main branch accidentally > got merged backwards into the 2.1 maintenance branch instead of the > other way around. In order to fix this and not have the history > completely unintelligible, I force-pushed the 2.1 maintenance branch > back to the commit just prior. It was just the single merge commit > that grabbed the main branch that needed to be removed to fix things > in the 2.1 branch. Only the 2.1 branch was affected. The main branch > did not need to be corrected so drastically. But, after I fixed the > 2.1 branch, I did merge it forward into the main branch as per our > usual procedure, to complete the original task that was being > attempted. > > tl;dr - > If you're curious, the relevant tickets were #3082, #3101, and #3102. > #3082 was the original ticket adding a feature to 2.1.1. #3101 > correctly reverted it from the 2.1 branch. This revert was then > attempted to be merged into the main branch. That was done as a > separate PR in #3102. For what it's worth, I don't recommend doing > merges using the GitHub UI that way. GitHub assumes you're combining > the history of both branches fully into a single resulting branch, > instead of merely incorporating one branch into the other. This > assumption caused several problems. The first is the presence of a > very risky "delete" button suggesting the 2.1 branch can be deleted > when we don't want it to be deleted. The second, and more troublesome > problem that caused the issues we needed to fix, was that GitHub's > conflict resolution UI will merge all of the main branch into the 2.1 > branch during conflict resolution, because it believes you're merely > bringing the 2.1 branch up-to-date with main in order to merge a > feature branch into main and remove the feature branch. It assumes a > feature branch workflow, not a maintenance branch, one-way merge, > workflow. > > In order to avoid problems like this in future, I recommend merging > into the main branch from the maintenance branches by using the > command-line. `git mergetool` is your friend :) > > I hope this explanation helps others understand what happened and how > to avoid similar issues with GitHub in future. > > Regards, > Christopher Tubbs
