if you want I can troll through submissions to get a bunch of these but here's one I saw yesterday https://continuum-app.xyz
see that little "Built for equity compensation" pill with the green dot? Those dots usually denote some kind of status (like things are up/down/enabled/disabled). By default nearly every LLM website seems to be dark mode with that dang status pill. once you notice it you will see it everywhere.
Lmao I had to axe one of those status pills from an LLM build of an internal tool. Connected to literally nothing too btw, no attempt to check the actual status of the backend made, it would stay "connected" regardless.
> Customers can be reassured that the Facewatch system has a 99.98% accuracy rate, and every match is reviewed by a trained manager.
That's not "reassuring" at all. If Sainsbury's gets, say, 10M customers per week, then that means 2,000 people per week are being falsely accused.
Likewise, if you visit Sainsbury's twice a week for groceries, the odds are favorable that at some point in your life you will be falsely accused, even with a 99.98% accuracy rate.
As I understand it, it's a combination of things: aircraft reports, atmospheric motion vectors (e.g. a cloud doesn't have any propulsion, so if a cloud moves 30 km in an hour, you have learned something about the wind), Doppler wind lidar, and satellite measurements.
The numerical predictions of weather models often have many vertical components as well, so solving it for ground level also requires extending the forecast to the air, depending on the model.
To predict anything on the ground, you have to predict air temperature, humidity, wind speed and direction etc. for the entire troposphere. The output of the models in altitude are as relevant to the meteorologists as the output on the ground for manual expert analysis.
> Jane Street has generated more than $40bn in net trading revenues in the year to Friday, even accounting for the July loss, which exceeds its entire haul for 2025, according to one of the people familiar with the matter.
This would make JS one of the most profitable trading firms of all time even with the loss.
But then what does it mean when the FT writes that that "revenue" number already accounts for the 15 billion losses? That the FT doesn't use these terms correctly either, and we can't really know what its reporting means?
That’s the correct usage. Revenue includes gains and losses. Profit will take that number and subtract out the operational costs (salaries, market data subs, etc).
It’s trading profit. No one is counting their gains from a trade while including their rent into it.
It’s a much easier to understand metric when you are discussing losses on a trade. No one is calculating losses including salaries.
It means Jane Street is still highly profitable in trades this year despite making a bad bet. If they have overhead that eclipses that, that is an entirely different metric.
Are they "trading" or "high-frequency-ripping-off-retail-investors"?
It's easy to make paper billions with synthetic shares and infinite deadline extensions for settlement. I'm old and still remember when Ken Griffin was lauded a clever person before he got caught with his hands in the GME mayo jar..
Liquidity providers like Jane Street, Citadel, et al make money on the spread. They also buy order flows from integrators, and retail investor order flows are now a product.
i.e. retail investor → brokerage platform → clearing/execution infrastructure → Jane Street → payment back toward the brokerage side of the chain.
Who captures the economic value created by retail order flow?
Jane Street.
In an ideal market, this product line shouldn't exist. Institutional investors should not be making money on the activity of retail investors.
What incentives determine where that flow is sent, and would investors receive better execution if their orders were exposed to genuinely competitive price formation rather than privately internalised by a concentrated group of wholesalers?
The regulators should be squashing any HFT related or retail order flow, but it's so opaque _by design_ that getting policymakers, or the general public, to understand that retail investors are paying some portion of tax on their $20T USD annual trades to these companies.
Granted, these order flows _sometimes_ work the other way -- and retail users get a better deal on a trade.. But would you really expect the market to be worth what it is, if that was the case less more often than not?
There is a clear and obvious conflict: the broker is supposed to seek the best execution for the customer while potentially being paid by the firm receiving that customer’s order. How can that be, when the broker's in bed with the liquidity providers?
PFOF and HFT are distinct concepts, but they are widely conflated in this thread. I don't agree that PFOF is inherently bad, but even if it were: it is not a valid criticism of HFT.
HFT raises pricing for retail traders by allowing front running of trades and makes the market less competitive overall for those without the infrastructure to do so. This isn’t even in question.
It's very much in question. As much as I hate to admit that since I do not like the concept of HFT existing as it's not providing very much value to society (imo) compared to the money made. The intellectual power behind this stuff would be much better put to use for something productive.
It likely lowers the transaction costs due to adding liquidity and narrowing bid/ask spreads for small retail orders.
But indirectly it likely raises costs for institutional investors like pension funds and large ETF managers making giant block trades on behalf their beneficiaries.
So tldr; Probably fractionally better pricing for your $5k GOOG trade, fractionally worse for your VOO holdings over the long term.
Does it really hurt institutional traders? How? Is it based on the idea that they can’t get the retail spreads? Because there is no world where they would have ever gotten them. A market maker would loose money doing that.
I'm certainly no expert whatsoever. This is just my understanding from talking with a few folks I consider quite smart who work in the space. Some working for HFT firms, some elsewhere. Also reading on the topic over the years.
There does seem to at least be some evidence that HFT firms decrease retail spreads overall. Either way, my main point being made is that negative impact to retail traders is very much in question.
Market makers are simply an artifact due to how shares are traded based on limitations that existed before computers. The aren’t some inherent aspect of having a stock market.
The money isn’t coming from thin air. If N people trade a a finite set of shares back and forth every day the only way to extract money from that set of people is for them to lose money.
Yeah, the stock market may be positive sum over the long-term, but it's certainly zero sum over the millisecond-term. Whether it's "retail" or "institutional" that is paying for HFT profits, it's all retail in the end.
The millisecond-term zero sum game is part of what allows for a positive sum long term. For example, zero fee trading was pioneered by Robinhood and only possible because of payment for order flow, and as a result it's virtually unheard of now for retail to be paying per transaction. Now more retail investors can participate and everyone benefits. You can also point to lower spreads and faster execution as direct benefits.
No one? Mutual funds have managed to attract $33 trillion trading once a day. The demand for millisecond-level trading is almost entirely from a very small group of firms profiting from it.
And they are steadily losing new investment dollars to ETFs, which trade interday. I don't think interday trading is why ETFs are more attractive to all or most investors, but a 0.000001% (or whatever) cost advantage just falls below the noise floor. It isn't worth any other tradeoff.
That's true, we don't want it to do that, we want it to kill these parasitic entities. Much like one doesn't swat a mosquito because one will truly miss the amount of blood she's taking.
> it's certainly zero sum over the millisecond-term.
Why do you think market-making is zero sum? Providing liquidity has value and market makers are compensated for that. (Milliseconds of liquidity being appropriately compensated with fractions of pennies.)
Again, the costs are de minimis and they're just competing with other, slower market makers to provide the same service at lower costs and faster speeds. Who cares? Retail investors, rationally, should not care about this at all.
If the costs where actually de minimis nobody would be fighting on those timescales, instead the costs paid by the market is the full operating budget of these companies plus their profits plus their negative externalities which combined ends up being significant.
Ultimately the primping value of markets is in information gathering and by flooding the market with trades based on ms timescales you’re masking important signals with meaningless white noise.
> trade something like $500B/day of volume or like $125T/year
Trade volume is meaningless in the face of HFT. The very actions you’re defending prove the numbers you just presented have zero relevance and could increase by 100x with zero benefit to anyone.
However step back a second. Quoting a number roughly equivalent to global GDP is frankly silly here, but it’s an easy enough mistake to make when your basic premise is inherently flawed.
> No. Combined, it is still de minimis. US equity markets alone trade something like $500B/day of volume or like $125T/year.
If that was what you where trying to describe the second sentence is unconnected to the first.
> half a penny per share traded
That’s far from de minimis. Rebalancing a portfolio now becomes quite expensive over a lifetime. You lose 0.5c selling and 0.5c buying, on say a 10$ stock and that’s 0.1% per transaction, and you don’t rebalance once.
Isn’t Ken Griffin still considered very clever? Citadel is one of the most successful hedge funds of the is era and has largely accelerated since 2020.
There's this famous line item which is called something like "securities sold but not yet purchased", e.g. with their market maker privilege Citadel can create infinite synthetic shares out of thin air to facilitate that a trade happens, but they have abused this privilege on a very large scale which has created an idiosyncratic risk to all stock market investors.
Due to regulatory capture of the SEC this risk has not materialized in an overall market crash, but they have done numerous accounting shenanigans and deadline extensions to give Citadel more room to breathe.
This statement doesn't go far enough given Elon's direct and hands-on involvement with DOGE and the 2024 elections. Very few of the richest people of the world are personally entangled in meddling with government agencies directly, for example.
A poem I wrote based on the phrases the LLMs I use most are likely to overuse:
How to unpack
The self within?
What do I lack?
Where to begin?
Great question — real.
Let's dive right in:
Name what you feel;
That's the linchpin.
It's not the door,
It's not the key —
It's what you bore:
Your tapestry.
The quiet part
Out loud — that lands.
Load-bearing heart,
Held in both hands.
The smoking gun?
That you walked in.
The real work's done —
You're genuine.
Now hold this, too:
You do deserve
The softer view,
The gentler curve.
Unlatch the gate,
Honor the seam:
You resonate.
You are the theme.
Here is one I wrote a while back, unrelated to LLMs, yet a poem none the less.
The Rhythm of Time
The Sun rises,
The Sun sets.
Have I checked the mail?
No, not just yet.
The Sun rises,
The Sun sets.
Have I caught up with neighbors?
No, not just yet.
The Sun rises,
The Sun sets.
Have I spent time with friends?
No, not just yet.
The Sun rises,
The Sun sets.
Have I visited with family?
No, not just yet.
The Sun rises,
The Sun sets.
Have I told those I love I do?
No, not just yet.
The Sun rises,
The Sun sets.
Have I lost who I am?
No, not just yet.
For all I must do,
Any money I will bet.
Is to turn away from;
No, not just yet.
> No one is ever going back and reading individual commits.
I violently disagree with this.
At a minimum, when I review PRs I look at the commit history to understand what's up. If the path that was taken to commit this is full of "oops" and "fix" messages, it's an immediate reject for me. The commits tell the story and it's a kindness to your human reviewers to not make them work harder to understand the point you're trying to get across.
What's up with the fix commits? Maybe I misunderstood you, but there ain't nothing wrong in fixing stuff you offer in your PR. And there can also be multiple commits even before the PR while you're developing your PR.
They shouldn't show up in the commit history. In a PR, you merge them in the commit that they actually fix. Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message that is worse than having nothing.
Anyone can do better than a fixup commit. And doing metter means merging them into the actual commits that are fixed.
For a change small enough to fit in one commit, that works. For a larger merge, you might still want multiple commits merged together. For example "make the foobar extensible" and "extend the foobar to add the baz" are really two separate changes that may be merged as part of a single PR to add the baz.
“make the foobar extensible” has no value without also “adding baz”. If I need to remove baz, I can’t just revert “adding baz”. The extensible foobar needs to go as well because it’s a unused abstraction.
> Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message
Isn't this solved if you squash the commits when merging the PR? I personally don't care that much about the commits inside a PR, the are just temporary because when a PR is merged they are squashed and you only get one commit for the whole feature on the main branches
Most people who squash things have never used git bisect, cannot solve a merge conflict and when there is one will just delete the directory and clone everything again. I've worked with such people. They can go on like this for an entire lifetime.
For me (I know you used most, not all). A PR is an atomic thing. Either one bug or one feature. Commits inside it are mostly time snapshots, and fixing formatting and linting errors. If I where to properly present the PR, it will also have been a single commit.
A PR is an atomic thing, but at a higher level. It's an integration point. Merge commits are a great representation of an integration point. `git log --first-parent` gives you an integration log. Without `--first-parent` you have a "conversation log" with details about how PRs were formed.
`git bisect --first-parent` lets you start with your integration points (your PR merge commits), and because presumably you have Continuous Integration and make sure integrations points build and test successfully that should be a rather quick discovery run, and then when you discover the PR that introduced the issue, you have an opportunity to drill down into the even smaller specific change inside that PR that introduced the issue.
Merge commits are a navigation tool and an integration log. It seems useful to me to prefer them over rebases and squashes.
> you have an opportunity to drill down into the even smaller specific change inside that PR that introduced the issue.
But what would be the point?
Let’s say you found an issue in the first commit of the PR (assuming it’s curated and every commit can compile). But the PR is atomic, and later commits rely on the assumption made in the first one. You would need to replay the later changes as well to figure out the impact.
Squashing PR means you consider changes at an holistic level regardless of the workflow that created them. If a PR fails with a regression test, the whole thing is suspect, and I don’t really care when in the workflow it was introduced.
If I have a PR titled “Add support for flac files” that introduced a regression, I don’t really want to know if the bug is on the commit “extract sampling information” or the commit “support flac tags”, because what got released was the PR, not individual commits. Just like no one care if a typo was introduced in draft 5 or draft 8. The only things that matters is when it got published.
For me PR are releasable patches. Individual commits in them are the engineer’s workbench. Whether you want to curate the latter is up to you, as long as the PR is atomic.
The point is your ability to find needles in a haystack increases. A PR often is bigger than a 10-line change, but is often made up of smaller 10-line changes.
The ability to drill down with a second `git bisect` run (now with a known base and end commit, and even the ability to again use `--first-parent` to ignore merges inside the PR commit range) into the original contents of the PR is the ability to automate finding your needle in a 10-line change with its own git commit message and its context in the original conversation flow in the original PR.
That's a powerful ability.
Sure, you can probably comb the complete 100 or 1000 or 10,000 line PR to find the exact lines that caused that regression, you've narrowed down already to one useful haystack, but it's nice to have an optional second layer to break your haystacks down further sometimes.
(Especially if it turns out to be a regression from a merge commit inside that PR. Accidental bad merges happen all the time. Spotting them is hard sometimes. Spotting them after a rebase/squash happened is sometimes impossible because there's no unique record of the conflict resolutions unlike with a merge commit.)
> Sure, you can probably comb the complete 100 or 1000 or 10,000 line PR to find the exact lines that caused that regression, you've narrowed down already to one useful haystack
But the PR is one single atomic changes. even if it 100 or 1000 lines. This very measure makes it easy to review because there’s only one assumption change PR A (the good one) and PR B (the bad one and and also the current one).
Don’t forget that the codebase will also have several modules. With just one single patch, I can see which modules are affected and then reason where the bug may be. Using merge may not have helped as the 10 line changes in an individual commit may have been because that’s where I integrated stuff that was unused in the previous commits before the merge. That’s why an holistic view matters.
> Spotting them after a rebase/squash happened is sometimes impossible because there's no unique record of the conflict resolutions unlike with a merge commit
That’s something I never needed because the only thing that matters is codebase at state A, and codebase at state B, and the diff between those two states. Ideally, a single reason for the transition between the two.
I've had to deep regression analysis and archeology to make sure that regressions aren't recurring or stop recurring, because regressions can recur. An engineer that maybe read the wrong advice and got too eager in using a rerere cache only for it to cache bad regressions. Another engineer that missed a memo somewhere and regularly mismerges a feature thinking that work in progress is actually legacy code. A third engineer that accidentally committed temporary code used for testing that was more obvious looking at the exact commit where it was made than the PR it was made in.
There are so many such scenarios where more information is better. If you've got a good PR tool it might save caches of those branches pre-squash some amount of time and you can do some of that sort of archeology in your PR tool, but even GitHub will sometimes garbage collect PR commits from deleted branches eventually.
The git DAG being a two-dimensional data structure is a useful tool. I find that I want to preserve as much information as possible, including using `git merge --no-ff` in additional scenarios that many use `git rebase` for because I don't know when I will need that (integration or testing or process change) information, but if I find that I need that information it is good to have it.
It's related to the same reason we don't throw out commit messages on ancient commits. In my experience, no matter how outdated that information gets, you are going to find surprising reasons to need it. Source control isn't just about recent history, even if that is most of your day-to-day needs. Sometimes you do need to revisit the past and you don't always know exactly what you will need from that past until you do need that information search.
> I've had to deep regression analysis and archeology to make sure that regressions aren't recurring or stop recurring, because regressions can recur. An engineer that […] looking at the exact commit where it was made than the PR it was made in.
That mostly a staple of the merge workflows where people are crisscrossing merges all over the place. At the end you have those horrendous diffs.
A rebase (and squash) only considers the tip of the main branch (which is a working state) and add changes that bring it to the next working state. You’re always aware of the latest working model of the code because that’s the starting point of your work (not something from $days ago). There’s no bad merges in the history of the PR branch.
I've seen some really bad trainwreck merges in rebase heavy workflows, too. (Unwinding them is awful.) Rebases create just as many merge conflicts as merge commits do [0], but rebases don't save the evidence for them. Just because the evidence was lost of them doesn't mean the merge conflict markers were never there.
Any time you integrate two branches, no matter how long running or short running, you have possible merge conflicts. Like I said, I prefer keeping that integration log as a tangible source control artifact. I understand how many people don't care for it. But don't mistake it for solely an aesthetic choice. Merge conflicts are a necessary part of source control and sweeping them under the rug is one way with dealing with them, but in my opinion not exactly the healthiest way.
[0] ETA: Merge conflicts are not just a technical issue, but a communications and coordination issue. Software development is a social activity and as long as it is a social activity it creates merge conflicts.
I do agree that merge conflicts are a signal of a deeper collaboration issue.
> Merge conflicts are a necessary part of source control and sweeping them under the rug is one way with dealing with them, but in my opinion not exactly the healthiest way.
I don’t agree that retaining them is necessary. Merge workflows encourage long running branches. Sometimes divergence in understanding does not create conflicts and that’s how regression happens.
With most rebase workflow, the commit list is often kept short (which is why squashing them is often correct). Most of mine have been below five. Such patch is easy to review and reason according to the latest knowledge of the code. Also easier to cherrypick and apply to an old version of the code.
Use merge commits does not mean using "merge workflows with long running branches".
"Merge early and often" is just as useful of a concept as "rebase often". The workflow is often exactly the same. The only real difference is extra commits to mark the merge points, and the extra commits are mostly just a UI issue when code reviewing.
A good PR UI (and GitHub isn't always, but it tries) doesn't show commits brought in from the base branch. (I think GitHub would have a simpler thing if it defaulted to a simpler `--first-parent` approach (rather than trying to math from the base branch) with an option to drill down, but I'm not a a GitHub UX designer.
Don't confuse the workflow with the DAG shape, that is more aesthetic than not.
The only point not addressed by reviewing changes at a PR level instead of a commit level is
7. Break up large changelists
First a PR shouldn’t introduce scope screep, where you are actually introducing more than one change. And second.
Instead of changing everything at once, can you change the dependencies first and add the new feature in a subsequent changelist? Can you keep the codebase in a sane state if you add half of the feature now and the other half in the next changelist?
When the only reason to change a dependency is for a new feature, you keep everything together. That way, we can revert a feature at once without needing to hunt down related commits. I abhor unused code in the main branch.
And I say that if you can’t review a PR as a single patch, there’s bigger problem. As a reviewer, the only thing that matters is the change and its purpose, not a particular workflow/ritual.
Great! Now your bisect won't tell you if the issue is caused by the dependency or the use of the dependency and you will have to do more manual investigation!
Certainly a way to do things. Not the most useful or productive… but it's a way for sure.
> Isn't this solved if you squash the commits when merging the PR?
In theory, yes. Squashing is an extreme approach to merging fixup commits.
It also throws the baby out with the bathwater by removing individual commits that explain and clarify how and why some changes were introduced as part or a PR.
If your PRs are tiny and don't introduce major changes then squashing is ok. Instead, you should do the right thing and curate the set of commits featuring in your PR.
It depends on what you think "the right thing is".
Our right thing sounds different to your right thing. Our right thing is PRs less than 500~ lines, and a single logical change only if the overall goal is complex.
For example, in your "right thing" it sounds like you'll have a refactor commit somewhere in the chain of commits in your PR, that might introduce 2000 lines of change, and other logically coupled changes in the same PR, all resulting in a large PR.
We prefer smaller, complete, mergable PRs. And therefore we normally only ever start with a single commit in the PR because the dev squashes everything before raising.
I don't know which way is better, but I do know that when I come across large PRs, I zone out and review quality drops. In fact, I just don't approve them.
Making small atomic commits as you go in the age of AI tends not to go great because it forces too much human in the loop in a lot of cases, and the percentage of AI code rework is significantly higher than manual code, so the history tends to be harder to keep clean.
It's ironically easier to create a messy agent work branch then have the agent cherry pick independent PRs from it into atomic commits post-work.
> Making small atomic commits as you go in the age of AI tends not to go great because it forces too much human in the loop in a lot of cases (...)
You seem confused. In the age of AI your ai code assistants already do task-specific commits. In fact, you can easily create a skill to have ai do that for you. It can even use git history split.
You tidy up and rebase before making a PR. Anything else is really disrespectful of your reviewer's time. That is also how all the larger open source projects operate.
> you only get one commit for the whole feature
If you are doing one logical commit per PR, you are doing way too many PRs.
Alternatively you don't have a working review process.
Not really, because that one commit represent a logical changes to the codebase. It’s either in or not. Splitting it would be only cosmetic. That’s what a good PR in my opinion.
Presenting a series of patches is good in an email format because when I’m adding them, I can evaluate each and decide whether I want it or not. But GitHub (and forges that copies it) is lacking in that regards without me taking over the branch.
So the word is to make the PR the unit of changes, and only review the whole diff, not the individual commit.
That's one approach, sure, probably works best if your units of work (e.g. everything inside of a PR) are small and atomic though.
Other use cases exist where each individual commit adds value / changes something important / is atomic. Which one is best depends on the use case.
What should definitely be avoided (or, what should not end up in main) is "work log" commits. Many people use git commit like a save / checkpoint operation, that's the kind of thing nobody needs to read. That's the "fix" commits.
Succinct guideline:
Good commits: "When applied, this commit will <commit message>"
Bad commits: "I did <commit message>"
Then whether it's one commit or the result of a squash merge it doesn't really matter much anymore.
Just squash everything before merging and call it a day
That is also a line from top comment. Everyone read „perfectly curating git history” and went rage commenting instead of reading and understanding what OP wrote.
Nope. Perfectly curating history is indeed the opposite of squashing—you squash because you couldn't be bothered to curate your commits. Squashing is a workaround not an alternative solution.
You just contradicted your previous comment that was pointing out that fcraaldo is „spending effort in perfectly curating history” … or your comment was a joke with no indication it is a joke.
I interpreted "I squashed them" as "I used git rebase -i to squash the oopses and fixes". If that's not what the user does, and rather squashes the PRs, then indeed I would be disagreeing with him.
Yep, the curated history is the main branch, which the PR targets. The commit log in the Pr reflects the workflow of the author, which I have no interest in. As the reviewer, I’m only interested in the content (the description and the composite diff of the whole PR). I don’t review commit by commit.
Just squash everything before merging and call it a day.
He didn’t write „leave a mess”. So it feels you wrote knee jerk comment or just writing whatever you wanted to write disregarding whatever was written.
Parent doesn't have experience of working with codebases with slightly high than average code quality requirements.
In products s.a. storage, avionics, medical appliances etc. it's very typical to have a requirement for each commit to compile and to apply tests retroactively. I.e. once a test is added against an existing feature, it is run against every commit since the feature creation (this is also why git-bisect exists).
However, it's true that a lot of companies would probably do better with just rsync instead of Git. Their Git history is in such a bad state that it's basically useless. It just doesn't make sense to use such a complicated tool as Git to deal with the average workflow.
Depends what the git history is supposed to show. Personally, I prefer people to leave their mistakes and reversions - though I'd require more description messages than "oops" or "fix", something that explained why it was being reverted or swapped out would be the minimum.
Sometimes you try things one way and they don't work out, so you go in a different direction. Capturing why this happened and when can go a long way towards explaining downstream decisions that might seem confusing to someone with a fresh perspective.
One part of me wishes for multiple levels of logical commits.
When using GH we essentially have one level. The PR is the like a roll-up commit and then we have the component commits it consists of.
It would be nice to be able to say this commit consists of N component commits. Then users can expand or collapse the commits depending on what level of detail they want.
So user A who likes to keep a record of how they actually went through the process with all the warts can have those "messy" commits as component.
And user B who likes to see a coherent story told by the commits without unnecessary steps can look at the higher level commit.
This happens when people insist on the (rare) always-merge policy for PRs. You end up with a shorter chain of merge commits (one per PR) directly chained to each other on one side, and their other sides have several real commits between each merge. It's not the easiest structure to work with on the command line but it's clear in any visualiser.
yea I look at commits several times a week at least, especially when commits are tied to a ticketing system/project it helps a lot going back months later on a large codebase going “how/why did this change happen”
I do tend to squash or make my entire change in one commit though so maybe I misunderstood your comment. If I have a fix commit often I’ll just tag a separate PR/ticket to keep the change history/change control clean
I think that the path that was taken should include mistakes. It's natural that code at some point would contain bugs and mistakes. If anything, your approach would encourage to squash those commits into one just to make it being review-worthy, but that misses the point then.
It shouldn't be that path that was taken but the path that will be taken when the PR is merged, split up into as many self-contained steps as possible to ease review now as well as triage if problems are found later.
You sound pleasant to work with. I bet your coworkers route around you when they can, and when they can't they cherry pick from their working branch to deliver monolithic commits while rolling their eyes.
A professional with standards who wasn't also unpleasant would put the time in to review the content of the commits with a request to clean up the history. Someone who looks at the history, thinks to themselves "not how I like it" and just auto-rejects the entire PR without any further thought is just a bad coworker.
A programmer's job is to deliver business value to their employer. If you're slowing down PR turnaround by mindlessly auto-rejecting on stuff that the suits don't care about, you better have a rock solid case for why that is going to deliver business value down the line, otherwise you're actively sabotaging your employer to bikeshed your personal preferences, which is the hallmark of a bad employee.
Rejecting an obviously bad PR after scanning the code quickly is one thing, burning business cycles on PR turnaround/latency to bikeshed bookkeeping without spending any time on the actual value producing portion of the PR is just bad. At the minimum you wasted an opportunity to give feedback on the proposed solution, thus probably necessitating another round of reviews, with the associated org latency.
In most business settings, the ticket is the unit of value to the business. If a ticket is to big, the best way is to split it into several ticket. Then you create a PR for each. There can be some automation that update the status of the ticket alongside the PR. Splitting a PR futher into commits doesn’t make any sense, because the whole business operates with tickets.
When I do it, it’s for my convenience. I expect the reviewer to review the diff at the PR level, not at the commit level. And when it’s approved, I’ll squash and merge, because only the whole PR matters.
When the commit is the unit of work (email workflow) I curate locally.
You are assuming that the only thing the business in question cares about is moving fast without any consideration for long-term health. I'd consider that a bad place to work at.
> Do you really care if someone forgot to format before committing?
Not OP but yes I definitely do. If you expect others to spend time reviewing your code, you are obligated to start off by reviewing it yourself. Posting a mess helps no one and makes code harder to audit.
I really really really do not want the autoformatter stuff happening in the same commit as where the real thing happens. I don't care to review if the autoformatter is working properly.
Oh that is such a bad heuristic ! The commits and history of how a PR was put together is no indicator of the quality of the PR or the thought process that led to it. Thats the equivalent of rejecting a (handwritten) essay for having too many corrections. ridiculous.
The code is all that should matter. Maybe comments for being nice to others and my future self. thats it.
This is one of those ideas that would really benefit from a short video demo, gif, or even a screenshot directly in the README. Otherwise, the title reads like a "Curtains for Zoosha?" meme. [0]
For me, once a couple words loaded the cadence/pace of the streaming words in the response was so recognizably “ChatGPT” it immediately lost the sorta eerie mysterious feel and almost veered into parody/comedy.
Like imagining the wizarding world full of Hogwarts students writing out prompts for “Write a 500 word history of the polyjuice potion, sound natural using my own voice, do not use em dashes, no mistakes.”
I expected, from the description, it to look like text was being written by hand -- with the letterforms being stroked at roughly human pen speeds. Not just a fancy font over a text box being entered character by character. The description WAY oversells it.
I remember for roughly a month after Elon bought twitter he opened the site up again and public viewers could browse it. Now you can't even click play on a video lol.
An incognito window let me watch the whole 25 seconds with the user writing something and three book writing back, but I don't know if my IP or incognito cookies or anything else are special.
It would be ironic if you have to actually sign out from Twitter, not just use incognito mode, to bypass the signup nag. Or if they mark IPs as “signed up” or something. Thanks.
Doesn't work for me, Chrome on Mac. Used a private window to test not being logged in. Got nothing against Twitter, but if I didn't already have an account, definitely wouldn't bother making one just to watch a video.
Can't use the Twitter links if you don't have a Twitter account. Also, why make the user click away when they're trying to understand if your product does something interesting, and why do they need an account on an unrelated service when an image/gif embed would get the message across in 5 seconds?
There are many workarounds like xcancel and nitter.net and xcancel.com that have been operating for a couple of years now. This is Hacker News, not Consumer Reports.
> Otherwise, the title reads like a "Curtains for Zoosha?" meme.
This is also why capitalization is important. In the title, "remarkable" refers to "Remarkable Paper Pro", a tablet. Not knowing that "Fable turned remarkable into Tom Riddle's diary" is very hard to parse.
A Remarkable tablet was the first thing I thought of, but it was still so unclear I had to click through to actually understand (more or less) what was going on.
Harry Potter would have posted the original video to YouTube instead. It seems like a tragic irony, and perhaps a sign of danger, that OP posted the demo video to the website of He Who Should Not Be Named. Why? Why?!
Because Twitter posts consisting of YouTube links die quickly. It’s very obvious once you have a few thousand followers.
Your option is basically either upload to twitter, or put the YouTube link at the end just before a screenshot. Or both a video and a YouTube link, I suppose.
If you trigger their YouTube embed, it seems like it gets penalized quite harshly. I’ve seen other people agree with the sentiment.
Just don't use a Twitter post as your demo video in the GitHub readme. I don't care what someone does on Twitter - I never go there. But you can just embed a .gif or .webm in your readme or link to YouTube there.
I'm in the US and twitter videos don't play for me. I see what looks like a video control when I view the post, when I click it, it throws up a modal log in/sign in dialog. No way to view the video while logged out.
I don't have a twitter or x account. I clicked the link, a log in modal popped up, I dismissed it, then was able to play the video. Firefox on iPhone if it matters.
