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 think this is a fake quote that somebody made up for an Internet comedy bit

You can tell by the pixels

I mean, it’s posted in programming humor so yeah.

A bit of the old on the internet no-one knows you're a dog, I think. Therefore I am a webdev dog too.

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.

Because my new intel integrated graphics cause Wayland to run like a slideshow.

because some of the hardware I use is too old to run Wayland

Idk I hang out on Mastodon.social

If yall don't like the chronological feed then find a hashtag you like and start following people.

Because their name is Elon Musk.

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.

How others are keeping their branches up to date is their problem. If you use Gitlab you can set up squash policy for merge requests. All the abomination they’ve caused in their branch will turn into one nice commit to the main branch.

Git-illeterate illiterate

That was you! I remember this.

Could have been worse. I mean, like, imagine of you were using like CVS and you put a watch on the root! Haha and then like every trivial commit in the repo caused everyone to in the entire org to get an email and it crashed the email servers.

Like who'd even DO that?! Though, I bet if you met that guy he'd be ok. Like not a jerk, and pretty sorry for all those emails. A cool guy.

Merge is not the issue here, rebase would do the same.

You sent over twenty-two thousand notifications lmao.

And then the bot added about as many tags to the PR.

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.

She's an American actress who was in Handmaid's Tale and a few other things and then blew up thanks to her role in Euphoria. She's become a bit of a meme recently because online conservatives think that her boobs are anti-woke

Two reasons.

Holy shit

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.

Squash and rebase or squash or rebase?

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.

This is really the only sane way to do it. I have run into some wonkyness with the commit history of the target branch commits not resembling git log, but that's usually for commits outside of what I'm trying to merge.

Edit: squashing commits down this way also helps reduce problems with replaying commit history on the actual rebase. In most cases you don't need all your "microcommits" in the history, and fewer commits just takes less time to reconcile.

git config --global merge.ff no

I have been using something very similar to this. In my team I insisted on people without any git experience working on a separate local branch, than the feature branch

. To ensure screw ups are minimal, we pull and create a local feature branch and then a new local only dummy branch, on top of it. Once the team is more comfortable with git, I am planning to treat the local feature branch as a dummy branch.

So far things have been pretty neat. Spaghetti is no more with minimal conflicts.

I use interactive rebases to clean up the history of messy branches so they can be reviewed commit by commit, with each commit representing one logical unit or type of change.

Mind you, getting those wrong is a quick way to making commits disappear into nothingness. Still useful if you're careful. (Or you can just create a second temporary branch you can fall back onto of you need up your first once.)

Well, rebase allows you to resolve the same conflict ten times in a row instead of doing it once. How cool is that?

The way I structure my commits, it is usually (but not always) easier and more reliable for me to replay my commits one at a time on top of the main branch and see how each relatively small change needs to be adapted in isolation--running the full test suite at each step to verify that my changes were correct--than to be presented with a slew of changes all at once that result from marrying all of my changes with all of the changes made to the main branch at once. So I generally start by attempting a rebase and fall back to a merge if that ends up creating more problems than it solves.

make the commit message be "we’ve fixed bugs and improved performance. to experience the newest features and improvements, checkout the latest version of the branch."

Ah, yes, the good old git off --my lawn command.

Yeah totally merge everything, people like a good spaghetti salad.