Git rebase considered harmful


#1

After releasing a new product I had some time to evaluate JUCE 5 again.

One roadblock I stumbled upon was that as I need to merge our JUCE branch which contains various bug fixes, I discovered that it seems that ROLI rebases their commits which were already published on GitHub, so that I have in my history commits that I pulled from the main JUCE repo and the current JUCE repo holds duplicates of those but with different hashes… This makes the whole branching structure confusing and may also cause spurious and possibly error-prone merge work…

What is ROLI’s stance on rebase? Do you not avoid rebasing public commits?


#2

I’m a little puzzled by your comment because we have always avoided rebasing anything on the public branches. To do so would of course create problems like you’re describing, and it’s just common sense for us to avoid it.

I guess if you go way back in the history there may be a few moments where we had some sort of disaster and needed to quickly re-push a single commit, but you’d need to have been pretty unlucky to have just pulled it at the wrong moment for that to affect you!


#4

I see for example

Which looks like the same commit. But there are many others as well.

I guess cherry-picking to master are also possible and perhaps that’s what I’m seeing??


#5

Exactly!

Commits are usually pushed to the develop branch only, but when they are considered very valuable, they are also cherry-picked and pushed to the master branch.


#6

…and to be extra clear, in that case, for both commits (the original one on develop and the one resulting from its cherry-pick on master), the hashes are not going to change after you see them on GitHub