GSoC Commit History Slight Mess

[Alvin Wong]

Hi, I took a peek and it appears the branch has been rebased without 
actually resolving merge conflicts _and then_ merged with the 
non-rebased branch, and this has been done multiple times. This is why 
there are duplicated commits. Normally one should only rebase and 
force-push without merging.

Here I list all the merge commits and the "base" of their parents:

  * dc4612ae8909629bc8b2f045eafa87b56e1acf24 (2023-07-01 00:48:37)
      o Parent 1: 24813e070a4e965521e3e6fb91ac5440b3c77cc4
          + Base: a667f312a52960a2d9aa5499b1856864c5c66e22 (2023-06-30
            09:50:53)
      o Parent 2: bacde075314042be235284c28270d4b9f5cacde5
          + Base: 9e5c67b5051d2c18a427e5f84ef560993ebec44a (2023-05-19
            20:10:04)
  * 4fbdbac4920a37d0e9f48db605f9044896152e65 (2023-09-10 18:55:39)
      o Parent 1: cf19feaa2f07a3b76266e5e05e9d82f7b4ddb502 (2023-08-17
        17:15:10)
      o Parent 2: a693ee6d59170cb93e0cc547de01d6772f2715cc
          + Base: dc4612ae8909629bc8b2f045eafa87b56e1acf24
  * 63686b11c79b4ecc9641ae20bf45f825d5de4a05 (2023-09-10 19:06:18)
      o Parent 1: 765654c090060ea7478bc361809511b3244d102b
          + Base: f46c04aa3e3a248ac3e4805419534e17dcba7d23 (2023-09-10
            09:43:40)
      o Parent 2: 4fbdbac4920a37d0e9f48db605f9044896152e65 (No
        additional commits between the last merge)

I think the proper way to fix it is to redo the rebase on commits before 
those merge commits and cherry-pick manually, and properly resolve 
conflicts for each individual commit:

 1. Reset to bacde075314042be235284c28270d4b9f5cacde5
 2. Rebase onto master
 3. Cherry-pick commits before the second merge: `git cherry-pick
    dc4612ae8909629bc8b2f045eafa87b56e1acf24..a693ee6d59170cb93e0cc547de01d6772f2715cc`
 4. Cherry-pick commits after the third merge: `git cherry-pick
    63686b11c79b4ecc9641ae20bf45f825d5de4a05..5ff21d55b7ef8723c951545677807214455a9f48`

Unfortunately there will probably be a lot of merge conflicts to be 
resolved. If you want it to be a bit simpler, we can try to redo the 
merge commits instead:

 1. Reset to bacde075314042be235284c28270d4b9f5cacde5
 2. `git merge a667f312a52960a2d9aa5499b1856864c5c66e22`
 3. Cherry-pick commits before the second merge: `git cherry-pick
    dc4612ae8909629bc8b2f045eafa87b56e1acf24..a693ee6d59170cb93e0cc547de01d6772f2715cc`
 4. `git merge cf19feaa2f07a3b76266e5e05e9d82f7b4ddb502`
 5. `git merge f46c04aa3e3a248ac3e4805419534e17dcba7d23`
 6. Cherry-pick commits after the third merge: `git cherry-pick
    63686b11c79b4ecc9641ae20bf45f825d5de4a05..5ff21d55b7ef8723c951545677807214455a9f48`

See if this helps.

Alvin

On 19/9/2023 9:28, Emmet O'Neill wrote:
> Hey all, I just wanted to give everyone a bit of a heads up about a 
> small issue with merging Srirupa's GSoC today.
>
> The short version is that I think Srirupa has made a mistake in the 
> process of rebasing her work on top of master,
> leading to a bit of a mess with multiple duplicate commits and a few 
> extra commits fixing earlier merge conflicts.
>
> (At first it seemed to be able to be merged onto master with a merge 
> commit, but doing so would make a mess of our commit history
> and as Wolthera rightly pointed out, would make things like bisecting 
> a nightmare.)
>
> So anyway, git can't really make sense of it so I've started trying to 
> rebase/clean it up by hand and hopefully I'll have it sorted out 
> sometime tomorrow.
> Emmet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20230919/20bc77c3/attachment.htm>