Issues with Git History and Rebase Conflicts After 2.55.2 Release

Filipe P. · 2026-02-16T20:45:32.739Z

hey, I’ve noticed there was some issues with git history (recent push forces to dev/bugfix) and when I tried to rebase my fork with 2.55.2 I got many unexpected conflicts. Is it an issue introduced in 2.55.2 release and the recent push forces fixes them, so I should just skip merging 2.55.2? Thanks!

Issues with Git History and Rebase Conflicts After 2.55.2 Release | DefectDojo Community

10 comments

· Sorted by Oldest

chris (.
·
·
FYI Valentijn S.
Cody M.
·
·
Hi Filipe P. there is not an issue in 2.55.2, but since 2.55.3 came out today, I would recommend going with 2.55.3 instead!
Filipe P.
·
·
Thank you Cody M. - I was curious because of the conflicts that were added to PRs (conflicts with no actual changes) plus the oddly/high number of commits and conflicts (with unchanged files) when tyring to rebase one of my forks. Was it some push force? If so, could you the last “common” revision / where the rewrite began, so I rebuild from there instead of trying to resolve conflicts?
Valentijn S.
·
·
I would create a new branch from dev/bugfix and then cherry pick your commits onto the new branch.
Filipe P.
·
·
yeah did that for the PRs I had but wondering for the forks as I can’t just cherry pick all the commits there 😄 but all good, I’ll resolve conflicts
Valentijn S.
·
·
From my testing I concluded that rebase won't work as it will give you some unexplainable superfluous commits.
Cody M.
·
·
Have you tried this yet? https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork (edit: Enter sends in this work space rather than Shift+Enter 😅 )
Filipe P.
·
·
yes, I have and it worked on my public fork as I have no changes in master/dev I doubt it would work in the other fork as it has several changes on it But mostly I was wondering what exactly happened 😄 ? Because even in that screen of my fork it would show “12xxx commit behind, 13xxx commits ahead” (when there should be 0 ahead), that’s why I’m assuming there was a history rewrite/reset (and hence the conflicts on every file touched after the rewritten revision)
Marian G.
·
·
Hi I had exactly the same issue. The strange thing is that we already merged the internal master with the 2.54.0 release in January. That was a normal merge with some minor conflicts and roughly 300 commits. Then I wanted to upgrade to 2.55.3 and I also got many conflicts and around 12.000 commits from 2017 even. So, can it be that somehow the git history status was changed and now the local version can not be easily compared to the remote version?
Marian G.
·
·
The strange thing is: When I do a fresh pull of the open-Source version and compare the release/2.54.0 branch with our internal master (keep in mind we already merged the 2.54 version) I still see around 12.000 new commits and many conflicts, although the merge was done in January.

chris (.
·
·
FYI Valentijn S.
Cody M.
·
·
Hi Filipe P. there is not an issue in 2.55.2, but since 2.55.3 came out today, I would recommend going with 2.55.3 instead!
Filipe P.
·
·
Thank you Cody M. - I was curious because of the conflicts that were added to PRs (conflicts with no actual changes) plus the oddly/high number of commits and conflicts (with unchanged files) when tyring to rebase one of my forks. Was it some push force? If so, could you the last “common” revision / where the rewrite began, so I rebuild from there instead of trying to resolve conflicts?
Valentijn S.
·
·
I would create a new branch from dev/bugfix and then cherry pick your commits onto the new branch.
Filipe P.
·
·
yeah did that for the PRs I had but wondering for the forks as I can’t just cherry pick all the commits there 😄 but all good, I’ll resolve conflicts
Valentijn S.
·
·
From my testing I concluded that rebase won't work as it will give you some unexplainable superfluous commits.
Cody M.
·
·
Have you tried this yet? https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork (edit: Enter sends in this work space rather than Shift+Enter 😅 )
Filipe P.
·
·
yes, I have and it worked on my public fork as I have no changes in master/dev I doubt it would work in the other fork as it has several changes on it But mostly I was wondering what exactly happened 😄 ? Because even in that screen of my fork it would show “12xxx commit behind, 13xxx commits ahead” (when there should be 0 ahead), that’s why I’m assuming there was a history rewrite/reset (and hence the conflicts on every file touched after the rewritten revision)
Marian G.
·
·
Hi I had exactly the same issue. The strange thing is that we already merged the internal master with the 2.54.0 release in January. That was a normal merge with some minor conflicts and roughly 300 commits. Then I wanted to upgrade to 2.55.3 and I also got many conflicts and around 12.000 commits from 2017 even. So, can it be that somehow the git history status was changed and now the local version can not be easily compared to the remote version?
Marian G.
·
·
The strange thing is: When I do a fresh pull of the open-Source version and compare the release/2.54.0 branch with our internal master (keep in mind we already merged the 2.54 version) I still see around 12.000 new commits and many conflicts, although the merge was done in January.