Replies: 3 comments
|
Firs thing I did was to just allow |
0 replies
|
The command we can use to preserve merge commits during rebase is |
0 replies
|
We ended up redoing all the PRs since the Github transition manually. Done in the right sequence, this worked very well, with |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
The history of
devel(and thusmain) contains some unwanted commits that were not squashed. This happened because the squashing was not automatic thus far in our new Github repo (although there are some older unwanted commits too).We could thus clean
develusing interactive rebase (git rebase -i) and then force push todevel. This will change the history ofdevel, which will lead to the following problems:active feature branches cannot just rebase or merge
devel, because the history has been rewritten. A more careful approach is necessary to bring feature branches up-to-the-new-date:https://stackoverflow.com/questions/67854979/how-to-work-around-force-pushing-of-an-upstream-branch
The history of
maincontains the commits of the releases.mainis basically a copy ofdevelwith some additional commits. Indeed, we always performgit merge maininto a copy ofdeveland merge the ensuing branch intomain(with additional commits). Hencemainis like theupstreamofdevel, thus maybe a less complicated situation than point 1.Releases point to specific commits. Will these be affected by a change in the history?
All reactions