Commits on Oct 26, 2020

1. Recover the complicated situation after my bad merge …

   I made a mistake merge.  Reverting it in c778945 undid the state
   on master, but now I realize it crippled the git merge mechanism.
   As the merge contained a mix of commits from `master..staging-next`
   and other commits from `staging-next..staging`, it got the
   `staging-next` branch into a state that was difficult to recover.
   
   I reconstructed the "desired" state of staging-next tree by:
    - checking out the last commit of the problematic range: 4effe76
    - `git rebase -i --preserve-merges a8a018d` - dropping the mistaken
      merge commit and its revert from that range (while keeping
      reapplication from 4effe76)
    - merging the last unaffected staging-next commit (803ca85)
    - fortunately no other commits have been pushed to staging-next yet
    - applying a diff on staging-next to get it into that state

   

   vcunat committed Oct 26, 2020
   Copy the full SHA

   89023c3 View commit details

   Browse the repository at this point in the history

2. Merge branch 'staging-next' into staging …

   I re-verified that the git-tree state looks good after
   the trouble addressed in commit 89023c3
   (by the same approach - comparison to a "clean rebase").
   I was actually a little surprised that simple git merge
   did the right thing this time.
   
   The one thing I can't fix is that some of staging commits are now
   reachable from master even though they're not really applied in there
   yet, but that's just temporary effect until the next merge to master.
   I certainly don't envy any archeology hitting these commit ranges
   (e.g. bisections).

   

   vcunat committed Oct 26, 2020
   Copy the full SHA

   1111911 View commit details

   Browse the repository at this point in the history