Fixing the 2.1 branch - a brief analysis

[Christopher <ct...@apache.org>]

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

Re: Fixing the 2.1 branch - a brief analysis

[Dave Marion <dm...@gmail.com>]

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 <ct...@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 <ct...@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
>

Re: Fixing the 2.1 branch - a brief analysis

[Christopher <ct...@apache.org>]

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 <ct...@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