Live data from Hacker News

Toxic squash syndrome

en.wikipedia.org

51–54 of 54 posts

Re: Toxic squash syndrome

#51
post #43

What about bitter melon, which is a popular vegetable consumed throughout Asia?

Not the same molecules. In bitter melon it is mainly momordicine (an alkaloid) that seem to cause the bitterness.

Interesting! It looks like bitter melon also has cucurbitacins though. I wonder how you'd determine a bitter melon is producing toxic cucurbitacins before eating it, since it's already bitter from the momordicine?

Re: Toxic squash syndrome

#52
post #44

Earlier quoted context omitted.

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.

Can you expand on what merge+no-ff means?

i think it just means turning off merge fast-forwarding (git merge --no-ff, or config merge.ff=false) so that merges appear as explicit commits even when one side of the merge has no commits, where git would by default just zip them together making it appear as though no merge happened at all

less work than dealing with squashing, and easier to understand past branches than the default

Re: Toxic squash syndrome

#53
post #43

Earlier quoted context omitted.

Not the same molecules. In bitter melon it is mainly momordicine (an alkaloid) that seem to cause the bitterness.

Interesting! It looks like bitter melon also has cucurbitacins though. I wonder how you'd determine a bitter melon is producing toxic cucurbitacins before eating it, since it's already bitter from the momordicine?

Yes it could be tricky, and they really tend to cross-pollinate. The best way is to not grow it close to non-edible Curcubitaceae, which can be tricky in an environment with neighbors around. Also you don't tend to eat a lot of bitter melon at once maybe that could reduce the risk.

Re: Toxic squash syndrome

#54
post #37

Earlier quoted context omitted.

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 def…

> If you value none of those things, it's a total waste of time and energy.

This might be the case for me. I work on a relatively small dev team and luckily everyone has adhered to meaningful commit messages without needing any manual intervention.

I could imagine a time where this team is much larger and the commits begin to get out of hand. So perhaps my failure to appreciate squash-only repos is mainly a function of my relatively small team.

Post reply on HN