Live data from Hacker News

Toxic squash syndrome

en.wikipedia.org

31–40 of 54 posts

Re: Toxic squash syndrome

#31

Earlier quoted context omitted.

Your wife loves you very much and/or your nasty food poisoning had very nasty external effects.

> Your wife loves you very much That's generally the idea of marriage.

It wasn't some pointless observation of the obvious. The point was to explain why the wife now hates zuchinni.

Re: Toxic squash syndrome

#33

I once had a nasty case of food poisoning from a zucchini salad that I made. I always assumed it was from not washing them properly or undercooking them, but maybe this was it! In any case, my wife still hates zucchini even though it’s been many years since that incident.

Your wife loves you very much and/or your nasty food poisoning had very nasty external effects.

Why in the world is this downvoted? A wife has never adopted an attitude towards something in response to how it affected her husband? My girl does that all the time. So do I for that matter.

Re: Toxic squash syndrome

#34

When cooking zucchini it is worth chopping a slice in the middle and tasting it. If it’s bitter just throw it out. The worst is you cut 5 zucchini’s , and one bitter zucchini ruins your entire dish.

This is worth doing for cucumbers and loofah as well.

Re: Toxic squash syndrome

#35

For a second I thought this was going to be an article about people who only allow squash-commits to their repo

Was hoping for the same, so lets discuss...

Anyone have strong opinions about only allowing squash commits, vs allowing merge commits?

Having used both professionally, I don't think the benefits of squash commits only outweigh the hurdles for new developers. Merging is just easier, and I don't think the merge commits in master are really all that jarring?

Re: Toxic squash syndrome

#36

For a second I thought this was going to be an article about people who only allow squash-commits to their repo

Was hoping for the same, so lets discuss... Anyone have strong opinions about only allowing squash commits, vs allowing merge commits? Having used both professionally, I don't think the benefits of squash commits only outweigh the hurdles for new developers. Merging is just easier, and I don't think the merge commits in master are really all that jarring?

Reverting large squash commits or merge commits after other commits have been applied to the main/master branch will likely result in conflicts.

On the other hand, limiting commits to do a single thing and having several per merged branch allows one to revert a problematic commit without conflicts or isolate a bug using git bisect.

Re: Toxic squash syndrome

#37

For a second I thought this was going to be an article about people who only allow squash-commits to their repo

Was hoping for the same, so lets discuss... Anyone have strong opinions about only allowing squash commits, vs allowing merge commits? Having used both professionally, I don't think the benefits of squash commits only outweigh the hurdles for new developers. Merging is just easier, and I don't think the merge commits in master are really all that jarring?

I run squash-only repos. You can't just run a squash-only repo though; the practice is linked with things like trunk-based or branch-based development. More broadly, a single "thing" (feature/bug fix/task) needs to be done in a single merge.

That gets tricky too - what about features being developed by multiple engineers? Generally, I create a branch that embodies the full scope of work and devs treat that as the default branch while working on it - merging their branches into that one. That branch needs to be consistently rebased to be kept up to date in order to avoid conflicts, and devs will sometimes need to merge or rebase their own branches based on that branch. Usually, this isn't too complicated, unless someone buries their head in the sand for a little too long (pun intended.)

This also means that all CI jobs have to be configured to use the current branch rather than a static target - which makes logic a bit more complicated when dealing with things like E2E tests that create real environments.

What does it accomplish? A linear, well-constructed history and it ensures resilient CI jobs. The other side of that, is that the real product branch gets a very organized history, while feature development branches can have non-standard commit messages like, "I screwed up", and can allow force pushes that can't be done on my default branches. This allows for both clean history and me to not be policing people's commit messages. If you value none of those things, it's a total waste of time and energy.

Re: Toxic squash syndrome

#38

For a second I thought this was going to be an article about people who only allow squash-commits to their repo

Was hoping for the same, so lets discuss... Anyone have strong opinions about only allowing squash commits, vs allowing merge commits? Having used both professionally, I don't think the benefits of squash commits only outweigh the hurdles for new developers. Merging is just easier, and I don't think the merge commits in master are really all that jarring?

I used to be a big proponent of rebase+squash, but migrated everyone to merge+no-ff. I needed the previous commit to be easily accessible for CI purposes, and merge+no-ff gives it to you without the additional hassle of rebasing.

Re: Toxic squash syndrome

#39
As someone currently growing more cucumbers than I can handle (gardener problems), I've been eating at least 2 a day of a few different varieties, including a somewhat bitter pickling variety.

That said, I've never experienced the burping side effect many report. Makes me very curious what's going on metabolically to cause some to burp but not others. Can gas produced by the microbiome of the upper tracts of the intensities make it back up into ones stomach?? All very fascinating regardless.

Post reply on HN