Fair point, Margot Robbie

Margot Robbie, I was about to agree with you and thought that was a very reasonable take, until you tried to argue that git merge is better than git rebase, then I simply had to disregard the whole thing.

"Don't always trust what you read on the internet."

• Benjamin Franklin

But esteemed Academy Award nominated character actress and film director, Margot Robbie, if it's unlikely that Hollywood actress Sydney Sweeney said this... wouldn't it be just as unlikely that Margot Robbie would be here? Adding her own comment?

... are you projecting? Is there something you want to tell us esteemed Academy Award nominated character actress and film director Margot Robbie?

I do, I have yet to switch to Wayland

I use X because Cinnamon on Wayland has no option to change the keyboard layout

Wayland really doesn't like RDP/remote access, so X is the only way to go if you want that to work properly.

I tried it for a moment, made games stutter like hell, switched back. I know I need to go in and figure it out at some point, but it's hard to muster the energy when X, for the most part, works fine.

From what I've seen, it probably has to do with my Nvidia GPU.

History is written by the squashers.

Imagine working with a tangled spaghetti of history

I agree that merge is the easier strategy with amateurs. By amateurs I mean those who cannot be bothered to learn about rebase. But what you really lose there is a nice commit history. It's good to have, even if your primary strategy is merging. And people tend to create horrendous commit histories when they don't know how to edit them.

That was you! I remember this.

Skill issue tbh

She's an ~~Australian~~ American actress who blew up last year (she was in euphoria I think?), expect to see her in a ton of upcoming blockbusters.

Merge takes two commits and smooshes them together at their current state, and may require one commit to reconcile changes. Rebase takes a whole branch and moves it, as if you started working on it from a more recent base commit, and will ask you to reconcile changes as it replays history.

Merge is taking all the code from the master branch and combining it with the task branch, resulting in a commit for just the merge itself.

Rebase is "re-basing" where your task branch was created from off the master branch. It essentially takes all the commits from master that happened since you branched, REWRITES THE HISTORY of your task branch by inserting those master branch commits before all your existing commits, and effectively makes your task branch look like it was branched yesterday instead of like 4 weeks ago. You changed where your task branch originated on the master. You moved its base.

Atlassian does a fantastic writeup on this.

Merge keeps the original timeline. Your commits go in along with anything else that happened relative to the branch you based your work off (probably main). This generates a merge commit.

Rebase will replay all the commits that happened while you were doing your work before your commits happen, and then put yours at the HEAD, so that they are the most recent commits. You have to mitigate any conflicts that impact the same files as these commits are replayed, if any conflicts arise. These are resolved the same way any merge conflict is. There is no frivolous merge commit in this scenario.

TlDR; End result, everything that happened to the branch minus your work, happens. Then your stuff happens after. Much tidy and clean.

Merge gives an accurate view of the history but tends to be "cluttered" with multiple lines and merge commits. Rebase cleans that up and gives you a simple A->B->C view.

Personally I prefer merge because when I'm tracking down a bug and narrow it down to a specific commit, I get to see what change was made in what context. With rebase commits that change is in there, but it's out of context and cluttered up with zillions of other changes from the inherent merges and squashes that are included in that commit, making it harder to see what was changed and why. The same cluttered history is still in there but it's included in the commits instead of existing separately outside the commits.

I honestly can't see the point of a rebased A->B->C history because (a) it's inaccurate and (b) it makes debugging harder. Maybe I'm missing some major benefit? I'm willing to learn.

I remember learning about how to use this back in the day and what a game changer it was for my workflow.

Today I like to do all of the commits as I’m working. Maybe dozens or more as I chug along, marking off waypoints rather than logging actual changes. When I’m done a quick interactive rebase cleans up the history to meaningful commits quite nicely.

The fun part is that I will work with people sometimes who both swear that “rewriting history” is evil and should never be done, but also tell me how useful my commit logs are and want to know how I take such good notes as I go.