Thank you for your question. At least there is one person who shares opinion, when down-voting. This is good, because I know what I did wrong, and I highly respect any respectable feedback ;)
I really hate, when people down-vote, without giving any feedback what they don't like.
Levenshtein, in combination with Machine Learning and big data engines, like Apache Sparks, can do a good job comparing content as well ;)
Wanted to share another approach, and ideas to people who are interested in comparing strings, doing fuzzy searches, and searching for duplicated content.
I think they just forgot to link their train of thought. I have also used Levenshtein distance for deduplication comparisons so I can guess where the story came from.
The author is talking about the case where you have coherent commits, probably from multiple PRs/merges, that get merged into a main branch as a single commit.
Yeah, I can imagine it being annoying that sqashing in that case wipes the author attribution, when not everybody is doing PRs against the main branch.
However, calling all squash-merge workflows "stupid" without any nuance.. well that's "stupid" :)
I don't think there's much nuance in the "I don't know --first-parent exists" workflow. Yes, you may sometimes squash-merge a contribution coming from someone who can't use git well when you realize that it will just be simpler for everyone to do that than to demand them to clean their stuff up, but that's pretty much the only time you actually have a good reason to do that.
* git merge ALWAYS does a merge and git pull ALWAYS does a fast forward.
* git log --first-parent is the default. Have a git log --deep if you want to go down into branches.
If you use a workflow that always merges a PR with a merge commit, then git log --first-parent gives you a very nice linear history. I feel like if this was the default, so many arguments about squashing or rebasing workflows wouldn't be necessary to get our "linear history", everyone would just be doing merges and be happy with it. You get a clean top level history and you can dig down into the individual commits in a merge if you are bisecting for a bug.
I set merge.ff = false and alias ff to merge --ff-only. I don't use pull but I do have pull.ff = only set, just in case someday I do.
The graph log and the first-parent log serve different purposes and possibly shouldn't be the same command conceptually; this varies by user preference but the first-parent log is more of a "good default", generally. Merges do say "Merge" at the start, after all.
This is what I advise people to do in consulting engagements, too, it's not one of my personal quirks.
Do people actually share PR as in different people contributing to the same branch?
Also I can understand not squashing if the contribution comes from outside the organization. But in that case, I would expect a cleaned up history. But if every contribution is from members of the team, who can merge their own PR, squash merge is an easy way to get a clean history. Especially when most PR should be a single commit.
We do. If we are building out a feature, none of its code is merged into main until it is complete (if this is a big feature, we milestone into mergeable and releasable units).
The feature is represented by a Story in Jira and a feature branch for that story. Subtasks in jira are created and multiple developers can pick up the different subtasks. There is a personal branch per subtasks, and PRs are put up against the feature branch. Those subtasks are code reviewed, tested, and merged into the feature branch.
In the end, it is the feature branch that is merged (as a single merge commit and complete unit) into main, and may well have had contributions from multiple people.
I get your POV, but I’ve always considered that long-lived branches in the canonical repo (the one in the forge) other than the main one should be directly related to deployable artifacts. Anything else should be short-lived.
There can be experiment on the side that warrants your approach, but the amounts of merge going back and forth would make this hard to investigate (especially when blaming) I would prefer to have one single commit with a message that describe every contribution.
Unlike merge strategies, where squash-to-merge is almost always motivated by someone not knowing how to use the tools well, branching strategies can be very diverse and project-dependent for very good reasons. Some projects have to maintain multiple versions of the thing they produce simultaneously, others don't. Some projects effectively maintain a patchset on top of some external upstream project, some are the upstream that's being forked by others - and some are somewhere in-between. Sometimes you break half the world to slowly fix it afterwards in a long running refactor, often you don't. Often there's a single canonical repo where all work happens, sometimes there's not. There's no genuine one-size-fits-it-all, but fortunately, git is very flexible there.
Blame, bisect etc. work well with histories with lots of back-and-forth merging, as can be easily seen in Linux, so blaming is definitely not a reason not to do it this way if your project calls for it otherwise. Perhaps one issue with such workflow is that some popular review tools aren't exactly great at letting you review merge conflict resolutions.
Somewhat Linux-like. You could probably improve it purely from a git perspective by letting subtask dependencies be many-to-many (the commit graph is a dependency graph), but what you have is probably best for your whole Jira workflow.
I think the point is that if you have to squash, the PR-maker was already gitting wrong. They should have "squashed" on their end to one or more smaller, logically coherent commits, and then submitted that result.
It’s not “having to squash”. The intent was already for a PR to be a single commit. I could squash it on my end and merge by rebasing, but any alteration would then need to be force-pushed. So I don’t bother. I squash-merge when it’s ready and delete the branch.
Does orange peel not produce any CO2 / methane when left like this? I'm assuming there is some negative carbon footprint before this becomes a positive?
The ecological win definitely looks nice on paper, but whenever people talk about compost the carbon footprint / gas emissions is always at the front of people's minds, and I don't really see that discussed in the article.
The article does say
> Especially since, in addition to the double-win of dealing with waste and revitalising barren landscapes, richer woodlands also sequester greater amounts of carbon from the atmosphere – meaning little plots of regenerated land like this could ultimately help save the planet.
How long will it take for it to cross the CO2-neutral mark? Maybe a silly question, definitely not my area of expertese.
CO2 is going to be neutral for the peels. You're just transporting it from where the oranges grew to where they were dumped. The CO2 benefit is purely from the trees and other biomass that grow where they wouldn't be growing before.
As for methane, that's a good question. Orange peels are better than most things because the limonene inhibits methane producing bacteria. But you'd still get quite a bit in the deeper piles (that produce the anaerobic conditions needed for methane production).
Spreading them out more would help, but might interfere with the beneficial effects.
China could definitely do this, to offset the minuscule of the destruction they do with the dark fishing fleets around (and possibly in) protected marine areas.
The orange peel is going to decompose and produce CO2 either way. Methane is produced when there is not enough oxygen available while decomposing, which certainly seems a possibility if it's dumped in big piles.
Remember the orange trees took the CO2 out of the atmosphere to make the peels. Some of it, probably most of it, is going back into the atmosphere but some of it is going to become soil carbon which could be retained for decades
You're getting downvoted but it's a reasonable question if posed in good faith. The tl;dr is that there are really a few options for what could happen to those orange peels:
(1) Landfill burial
(1a) Without methane capture and use: Produces methane, relatively high short term warming potential.
(1b) With methane capture and use: Ends up as CO2 after burning the methane.
(2) Composting (this approach)
(2a) Mostly aerobic: Produces CO2
(2b) Mostly anaerobic: Produces methane
A deep pile that is never turned will decompose anaerobically, resulting in fairly undesirable methane. A shallower pile or one that is mixed well will result in mostly aerobic decomposition. The aerobic decomposition will produce CO2 but not huge amounts of it. Each hectare of land could absorb something like ~8 tons of CO2 per year; with 7 hectares, the CO2 emitted by composting 12t of oranges is going to be dwarfed by the new vegetation. After a few years when you're growing big trees, the rate of CO2 absorption might rise as high as 20-30t/year/hectare in costa rica's environment. And this is probably an underestimate, as the soil amendment of the orange peels seems to have stimulated faster regrowth than would have happened otherwise.
And perhaps more to the point: There isn't really a purely "no co2" way of disposing of organic matter other than perhaps burying it at the bottom of a deep mineshaft (but the co2 or methane will be produced anyway). Landfilling it is strictly worse - you still get the decomposition products, _or worse_ because you'll mostly get methane, but without producing useful soil byproducts.
Overall this project is a huge win on a carbon perspective and a waste reduction perspective.
It's not a reasonable question. What's the alternative for the orange peels? They were going to rot and release that CO2 whether they did it in a big pile here or somewhere else.
But seriously GP could have had a mental model that landfilled orange peels might sit there for a long time -- which depending on conditions and food could be true on human scales (like 10-40 years) but not on the scale of 100 years. Especially if the conditions were dry -- a dry orange peel is pretty robust. That's not likely to be the case in Costa Rica, but I'll forgive some naivety here absent demonstrated malice.
The way I understood it, the original article is saying the _only_ remaining differentiator is taste and the comment you replied to is saying "wrong, there are also other things, such as effort".
I don't necessarily interpret the comment you replied to as saying that "taste is not important", which seems like what you are replying to, just that it's not the only remaining thing.
I agree that taste gets you far. And I agree with all the examples of good taste that you brought up.
But even with impeccable taste, you still need to learn, try things, have ideas, change your mind etc.. putting all of that in the bucket of "taste" is stretching it..
However, having good taste when putting in the effort, gets your further than with effort alone. In fact, effort alone gets you nowhere, and taste alone gets you nowhere. Once you marry the two you get somewhere.
Aren’t you just making their point stronger? Effort is what is being replaced here, with some taste and a pile of AI (formerly effort) you can go to the moon.
In other words, it requires a tremendous amount of effort to fully communicate your tastes to the AI. Not everybody wants to expend the time or mental effort doing this! (Once we have more direct brain/computer interfaces, this effort will go down, but I expect it will not be eliminated fully)
This is the second time in two days I've seen a subthread here with folks seemingly debating whether or not defining and communicating requirements counts as work if the target of those requirements is an LLM system.
I'm confused as to why this is even a question. We used to call this "systems analysis" and it was like... a whole-ass career. LLMs seem to be remarkably capable of using the output, but they're not even close to the first software systems sold as being able to take requirements and turn them into working code (for various definitions of "requirements" and "working").
I'm also skeptical that direct brain interfaces would make this any less work; I don't think "typing" or "english" are the major barriers here, anymore than "drafting" is the major barrier to folks designing their own cars and houses... Any fool thinks they know what they need!
At some point, just an idea will be enough for your Neurolink to spawn an agent to create 1000 different versions of your idea along with things that mimic your tendencies. There will be no effort, only choice.
As both a software engineer and a creative, I absolutely do not want 1,000 versions of what I am trying to make generated for me. I don't care if it's free or even cheap. I want to make things.
I know this is a concept deeply alien to a lot of HN's userbase but I did not get into programming or making art to have finished products; that's a necessary function that is lovely when it's reached, but ultimately, I derive my enjoyment from The Process. The process of finding a problem a user has, and solving it.
And yes I'm sure Claude could do it faster than me (and only at the cost of a few acres of rainforest!) but again, you're missing the point. I enjoy the work. That is not a downside to me.
Deciding between 1000 different versions is a lot of effort IMO. With manual coding, you’re mostly deciding one decision point at a time, which is easier when you think about it. It just require foresight which comes from experience
Not really. The effort required to produce the same result has declined, but it has been on the decline for many decades already. That is nothing new. Of course, in the real world, nobody wants the same result over and over, so expectations will always expand to consume all of your available effort.
If there is some future where your effort has been replaced, it won't be AI that we're talking about.
Effort is still (and probably will always be) the hardest thing to replace.
Any time someone says AI can do this, and do that, and blah blah. I say ok, take the AI and go do that.. the barrier to entry is so low you should be able to do whatever you want. And they say, oh, no, I don't want to do that (or can't, or whatever). But it should be able to be done.. And I just nod, and sip my drink, and ...
.. and I'd like to point out these are seasoned professionals that I've seen put in effort into other things in their careers that have the capacity to literally do whatever is they want to do, especially now.. and they choose not to do so, at least not without someone guaranteeing them a paycheck or telling them they have to do it to survive.
> It made me angry because makes the point that natural selection has become ineffective on humans and thus intelligence declines unironically. There is no joke in that - all jokes build upon the assumption of this being true.
you seem pretty convinced that intelligence plays an important role in natural selection. I'd argue that decisiveness, confidence, looks, social skills all play a more important role. (I'm not saying that's a good thing)
I'm interested in understanding your point of view, can you elaborate on what you mean by "There is no joke in that"?
The only cases where I've had gemini step on my toes like that is when a) I realized my instructions were unclear or missing something b) my assumptions/instructions were flawed about how/why something needed to be done.
Instruction following has improved a lot since a few years ago but let's not pretend these things are perfect mate.
There's a certain capacity of instructions, albiet its quite high, at which point you will find them skipping points and drifting. It doesn't have to be ambiguity in instructions.
Interesting, props for coming up with a good name.
But it's weird to me to call this a "ratchet", and not just a custom lint rule. Since it sounds exactly like a lint rule.
The hard-coded count also sounds a bit like something that I would find annoying to maintain in the long run and it might be hard to get a feeling for whether or not the needle is moving in the right direction. - esp. when the count goes down and up in a few different places so the number stays the same.. you end up in a situtation where you're not entirely sure if the count goes up or down.
A different approach to that is to have your ratchet/lint-script that detects these "bad functions" write the file location and/or count to a "ratchets" file and keep that file in version control.
In CI if the rachet has changes, you can't merge because the tree is dirty, and you'd have to run it yourself and commit it locally, and the codeowner of the rachet file would have to approve.
at least that would be a slightly nicer approach that maintaining some hard-coded opaque count.
yeah that’s the way we do it at Notion. it’s important to store the allowed violation count in a file type that makes merges easy; we use TSV rather than JSON because dealing with commas and delimiters during merge conflict is super annoying and confusing.
right now we have one huge ratchet.json.tsv file with all violations but it’s getting pretty ungainly now that it’s >1mb length.
reply