Just wanted to say...

[dodexahedron]

It's been SO NICE to be able to perform re-bases without trouble, now that normal merges are being used!

That is all. 😅

[tig]

Sorry I was dum before. Thanks for helping me be less dum. ;-)

[dodexahedron]

The two commits that happened before the last one on v2_develop, and also the commit where the blue one comes into the purple one would have never happened or been necessary, had they been rebases.

If I'm trying to walk back and find where a change that broke something came from, I have to split my search in 3 places to resolve the ambiguities created by those merges (not counting the legit merges to origin/v2_develop).

[dodexahedron]

Also, the more specific your individual commits are, the more powerful and simultaneously easier this becomes, which is a rare combo. I didn't have to resolve any conflicts on this rebase nor on most of the others I've performed since the merge strategy was corrected.

Had my commits been bigger work dumps, I might have had a couple of conflicts to fix. But you fix them once and then they're fixed as if there never were a conflict. This is just one of many reasons I make so many commits. :)

[dodexahedron]

This all works the way it does because git really is basically just a transaction log.

Any given commit is NOT actually a full picture of the state of that branch at that point in time. It is the deltas, in order, from its base ref, to that point. So, rebasing is a fairly trivial operation, because it's just replaying those deltas. As long as that delta can be reconciled with the new base version, it all happens automatically with no fuss and no interaction.

[dodexahedron]

All that being said...

If you have a branch which you have already done some "bad" merging on, you shouldn't try to rebase it on any branch that you merged into it, unless you first reset to a point before that merge. There are a few possible results, none of which are great. Most often, it'll simply fail due to unresolvable history. The rest of the time, it'll end up duplicating commits from the other branches, along with all sorts of other unpleasant stuff. And that's because you now inextricably tied that branch's history to whatever happened between the original base and the commit you're merging from the source into your branch, but in a different order than it really happened. That could be hundreds of commits, covering several PRs. But in no case is it a good thing.

So just don't do it. :)

[dodexahedron]

There's also the --interactive option for the git rebase command, which I occasionally use.

What that does is, before it replays the commits on top of the new base, it gives you an opportunity to squash, reword, re-order, or drop any commits you've made. Play with that option if you like, but be careful until you're comfortable with things, because that whole log nature of git can make the impact of things like re-ordering commits non-obvious. Using a GUI tool for that is a good idea. GitKraken does it quite nicely, but I don't know if the free version has that feature enabled or not.

[dodexahedron]

Ha... The git discussion sub-thread in here points out a potential idea for a Terminal.Gui application: A TUI for git.