Christopher, Thanks for cleaning up my mess, I appreciate your help here. Your git-foo is stronger than mine :-) Lesson learned regarding the GitHub UI merge between major branches. The GH UI in this case is lacking several important features - 1) a warning, 2) it didn't show in the UI all of the files that were being merged back to 2.1, it only showed the modifications to the files in main. Once I hit the button to merge, it committed the changes in both branches concurrently.
On Thu, Dec 1, 2022 at 5:31 PM Christopher <ctubb...@apache.org> wrote: > 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 >
