Just pointing out here that "rue" is used to express "to regret", emphatically. Perhaps it is not the best name for a programming language.

That’s part of the reason for the name! “Rust” also has negative interpretations as well. A “rue” is also a kind of flower, and a “rust” is a kind of fungus.

Fair enough! I do like how others are framing this is as "write less code" -- if Rue makes one think more and more about the code that finally makes it to the production, that can be a real win.

Sounds fitting to me. Every line of code I wrote that ultimately didn't need code to begin with, is basically codified regrets checked into git.

The best code is the code not written, so perhaps it is the best name for a programming language?

With "servant leadership" in its current form being attributed to Greenleaf, here is the "source of truth" on servant leadership: https://greenleaf.org/what-is-servant-leadership/

"Growth" of those being led is a key concept it seems, which I would think is really only possible when the leader doesn't do everything by themselves as a die-hard servant, but utilizes the "leadership" part to help subordinates learn to lead themselves.

Granted this realm of ideas can be a gray-area, but it seems like servant leadership as presented by the author here does not incorporate the concept of growing those that they lead -- as indicated by the fact they have self-invented a new "buzzword" which actually seems to be involve the behaviors as laid out by servant leadership -- am I missing something?

Essentially, what information are they privy to that public is not? What asymmetry exists (timing, un-public information)? Is there any way for the public to be nearly as informed? What are they trading on? Upcoming funding changes (more money here -> buy, less money there --> sell)? COVID impact stands out.

Most "big" projects (huge chip foundries, etc.) require various forms of government approval (if not outright funding). They get asymmetry from knowing:

1. Sometimes that the project is happening before everyone else 2. If the project will or will not be approved or stopped e.g. in committee 3. Various other classified things like Dept of Defense briefings (if the Army says it needs XYZ component and plans to buy 10 billion worth of them, then buy the company that makes XYZ component).

It isn't necessarily that they have information the public doesn't (although it could be that, they would know about policy changes before the general public does). It could also be that they use their leadership position to push forward policies that benefit stocks that they own.

This could even happen for non-selfish reasons. If you genuinely believe that, e.g, "The future of America is BigTech," you'll both favor tech stocks in your portfolio and be more sympathetic to their lobbyists and favored bills.

There are 3 things always overlooked in this conversation.

- It’s not just representatives but their staff, family and friends. See the Covid scandals as an example.

- Often the information they’re privy to can come from their networks outside of government. The current transparency laws give us insights into their family members’ investments which is incredibly beneficial public knowledge.

- The current laws have no teeth and are not enforced well. Immediate disclosure should be required & automated for elected representatives, judges, family & staff within 24 hours. Late reporting should be immediate sale and loss of any profits.

If you compared Pelosi to other investors in San Francisco, you wouldn’t see much of a difference. Anyone who has gone heavy into tech in the last couple of decades has outperformed the market at considerable risk of going broke if there was a tech bust. Compare Facebook or Google to an index fund, especially before index funds decides to go heavy into FAANGs.

People who make/have more money also have more appetite for risk and also in general make more returns. Even without insider trading, being able to take a lopsided position on tech with the expectation that if it loses you still have a comfortable life, that is how the rich become richer.

That doesn't explain why persons in leadership positions outperform other members of congress. Presumably they all talk to each other and could share trading strategies. There's no reason not to unless your strategy involves inside information that might get you in trouble if spread around.

It actually does, if you believe that the people in leadership positions have been earning money for longer and have more experience in investing. You could also easily argue that they are more successful in general than congress people of similar tenure who aren't in leadership positions.

You are basically comparing the CEO to middle layer management, and then what do you expect? You need to do a more balanced comparison than that to show an actual discrepancy. Or maybe get congress to dole leadership positions out at random and then compare?

I’m not defending congressional trading, but there are potentially other confounding variables (emphasis on potential). Leaders may tend to be older, have more appetite for risk, or leadership may correlate with wealth/status because “the connected” can also raise more money etc etc. Unless those types of variables are controlled for, it should temper how strongly we draw conclusions.

Where is AI actually selling and doing well? What's a good resource for these numbers? What are the smaller scale use-cases where AI is selling well?

I am generally curious, because LLMs, VLMs, generative AI, advances are proving useful, but the societal impact scale and at this the desired rate is not revealing itself.

Coding - e.g. Claude Code, Cursor both announced 1B revenue run rates.

That would be meaningful if they weren’t losing money to generate that revenue.

The product works and saves enough human effort to justify the real cost. People will eventually pay when it comes down to it.

If that were the case, why not charge more?

Because they're loss-leading like all their competitors for now

I am running a container on an old 7700k with a 1080ti that gives me vscode completions with rag with similar latency and enough accuracy to be useful for boilerplate etc…

That is something I would possibly pay for but as the failures on complex tasks are so expensive, this seems to be a major use case and will just be a commodity.

Creating the scaffolding for a jwt token or other similar tasks will be a race to the bottom IMHO although valuable and tractable.

IMHO they are going to have to find ways to build a mote, and what these tools are really bad at is the problem domains that make your code valuable.

Basically anything that can be vibe coded can be trivially duplicated and the big companies will just kill off the small guys who are required to pay the bills.

Something like surveillance capitalism will need to be found to generate revenue needed for the scale of Microsoft etc…

Given how every CPU vendor seems to push for some kind of NPU, local running models will probably be far more common in next 5 years. And convincing everyone to pay subscription for very minimal improvements in functionality gonna be hard.

The NPUs integrated into CPU SoCs are very small compared to even integrated GPUs, much less discrete or datacenter GPUs.

NPUs seem to be targeted towards running tiny ML models at very low power, not running large AI models.

Have you documented your VSCode setup somewhere? I've been looking to implement something like that. Does your setup provide next edit suggestions too?

I keep idly wondering what would be the market for a plug and play LLM runner. Some toaster sized box with the capability to run exclusively offline/local. Plug it into your network, give your primary machine the IP, and away you go.

Of course, the market segment who would be most interested, probably has the expertise and funds to setup something with better horsepower than could be offered in a one size fits all solution.

Kinda like https://www.microcenter.com/site/brands/nvidia-dgx-spark.asp...?

Ooof, right idea but $4k is definitely more than I would be comfortable paying for a dedicated appliance.

Still, glad to see someone is making the product.

I am working on a larger project about containers and isolation stronger than current conventions but short kata etc…

But if you follow the podman instructions for cuda, the llama.cpp shows you how to use their plugin here

https://github.com/ggml-org/llama.vscode

Market size for this is in the billions though, not trillions.

it's easily a 200bn ARR business, if coding agent achieved another step jump in abilities ~ 1trn+ marketcap

> if coding agent achieved another step jump in abilities ~ 1trn+ marketcap

Do you want to walk us through that math?

Agreed, coding is one. What else?

Professional legal services seem to be picking up steam. Which sort of makes sense as a natural follow on to programming, given that 'the law' is basically codified natural language.

I don't know how it is in other countries, but in the UK using LLMs for any form of paid legal services is hugely forbidden, and would also be insanely embarrassing. Like, 'turns out nobody had any qualifications and they were sending all the work to mechanical Turks in third world countries, who they refused to pay' levels of embarrassing.

I say this as someone who once had the bright idea of sending deadline reminders, complete with full names of cases, to my smart watch. It worked great and made me much more organised until my managers had to have a little chat about data protection and confidentiality and 'sorry, what the hell were you thinking?'. I am no stranger to embarrassing attempts to jump the technological gun, or the wonders of automation in time saving.

But absolutely nobody in any professional legal context in the UK, that I can imagine, would use LLMs with any more gusto and pride than an industrial pack of diarrhoea relief pills or something - if you ever saw it in an office, you'd just hope it was for personal use and still feel a bit funny about shaking their hands.

Except that it keeps getting lawyers into trouble when they use it.

https://www.reuters.com/legal/government/judge-disqualifies-...

Yeah, good point. These things never get better.

Newsrooms, translation services.

sales, marketing, customer support, oh my, so many

I don't use it, but I know several people who use ChatGPT to edit emails etc. so they don't come across nasty. How well it works, I can't say.

Most of my family uses ChatGPT instead of Google to answer questions, despite my warnings that it’ll just make stuff up. I definitely Google much less now than I used to, directing a fair amount of that into ChatGPT instead.

But how much are you paying for these services?

My family? Same as they pay for Google

that's frankly mostly because google search got so massively worse... I'd still use google more if not for the fact the stuff I asked it 5 years ago and got answer no longer provides useful answers

you can check on trustmrr.com (mostly indie/solo businesses) that a large chunk of those smaller companies make money by selling AI video generation and other genAI services.

Is this being used internally at Google? What's the "dog-fooding" situation and is it leading to productivity enhancements?

This def needs skins next: https://skins.webamp.org/

https://archive.org/details/winampskins_major_tom_v5_1 was a true work of art

It feels like making a UI with skins is a lot easier. Just draw the bitmap onto the window, and set some areas to be clickable (and change the bitmap of that area to "button is being pushed" when the user is holding the mouse down)...

At this point, you may as well get a powerpack for a mini and put it in one of these slings, you could have a crazy powerful machine in your "sock-et" sling thing here...

When the iPhone Air was just another huge phone...but thinner...smh. Apple should put up some page to check interest level in a smaller phone, and with enough interest, go manufacture it. If it is more expensive because economies of scale don't work out, but they create one that is small yet powerful, that's what I would buy at premium, because apparently compactness is a luxury.

Yes, applied research has yielded the modern expert system, which is really useful to experts who know what they are doing.

It's not the "modern expert system", unless you're throwing away the existing definition of "expert system" entirely, and re-using the term-of-art to mean "system that has something to do with experts".

I don't know what the parent was referring to, but IMO "expert system" is one of the more accurate and insightful ways of describing LLMs.

An expert system is generically a system of declarative rules, capturing an expert's knowledge, that can be used to solve problems.

Traditionally expert systems are symbolic systems, representing the rules in a language such as Prolog, with these rules having been laboriously hand derived, but none of this seems core to the definition.

A pre-trained LLM can be considered as an expert system that captures the rules of auto-regressive language generation needed to predict the training data. These rules are represented by the weights of a transformer, and were learnt by SGD rather than hand coded, but so what?

If you can extract anything resembling a declarative rule from the weights of a transformer, I will put you in for a Turing award.

Expert systems are a specific kind of thing (see https://en.wikipedia.org/wiki/Expert_system#Software_archite...): any definition you've read is a description. If the definition includes GPT models, the definition is imprecise.

Well, OK, perhaps not a declarative rule, more a procedural one (induction heads copying data around, and all that) given the mechanics of transformer layers, but does it really make a conceptual difference?

Would you quibble if an expert system was procedurally coded in C++ rather than in Prolog? "You see this pattern, do this".

Yes, it makes a conceptual difference. Expert systems make decisions according to an explicit, explicable world model consisting of a database of facts, which can be cleanly separated from the I/O subsystems. This does not describe a transformer-based generative language model. The mathematical approaches for bounding the behaviour of a language model are completely different to those involved in bounding the behaviour of an expert system. (And I do mean completely different: computer programs and formal logic are unified in fields like descriptive complexity theory, but I'm not aware of any way to sensibly unify mathematical models of expert systems and LLMs under the same umbrella – unless you cheat and say something like cybernetics.)

You could compile an expert system into C++, and I'd still call it an expert system (even if the declarative version was never written down), but most C++ programs are not expert systems. Heck, a lot of Prolog programs aren't! To the extent a C++ program representing GPT inference is an expert system, it's the trivial expert system with one fact.

What are you using it for? Is it part of a hybrid search system (keyword + vector)?

In Discourse embeddings power:

- Related Topics, a list of topics to read next, which uses embeddings of the current topic as the key to search for similar ones

- Suggesting tags and categories when composing a new topic

- Augmented search

- RAG for uploaded files

what does the rag for uploaded files do in discourse?

also, when i run a discourse search does it really do both a regular keyword search and a vector search? how do you combine results?

does all discourse instances have those features? for example, internals.rust-lang.org, do they use pgvector?

> what does the rag for uploaded files do in discourse?

You can upload files that will act as RAG files for an AI bot. The bot can also have access to forum content, plus the ability to run tools in our sandboxed JS environment, making it possible for Discourse to host AI bots.

> also, when i run a discourse search does it really do both a regular keyword search and a vector search? how do you combine results?

Yes, it does both. In the full page search it does keyword first, then vector asynchronously, which can be toggled by the user in the UI. It's auto toggled when keyword has zero results now. Results are combined using reciprocal rank fusion.

In the quick header search we simply append vector search to keyword search results when keyword returns less than 4 results.

> does all discourse instances have those features? for example, internals.rust-lang.org, do they use pgvector?

Yes, all use PGvector. In our hosting all instances default to having the vector features enabled, we run embeddings using https://github.com/huggingface/text-embeddings-inference

Thanks for the details. Also, always appreciated Discord's engineering blog posts. Lots of interesting stories, and nice to see a company discuss using Elixir at scale.

Discourse, not Discord.

`git-bisect` is legit if you have to do the history archaeological digging. Though, there is the open question of how git commit history is maintained, the squash-and-merge vs. just retain all history. With squash-and-merge you're looking at the merged pull-request versus with full history you can find the true code-level inflection point.

Can someone explain why anyone would want non-squashed PRs?

For the 5% of engineers that diligently split each PR into nice semantic changes, I suppose that's nice. But the vast majority of engineers don't do this. Individual commits in a PR are testing and iteration. You don't want to read though that.

Unless, of course, you're asking the engineer to squash on their end before making the PR. But what's the value in that ceremony?

Each PR being squashed to 1 commit is nice and easy to reason about. If you truly care about making more semantic history, split the work into multiple PRs.

For that matter, why merge? Rebase it on top. It's so much cleaner. It's atomic and hermetic.

Crafting a PR as an easily-consumed, logical sequence of commits is particularly useful in open source.

1. It makes review much easier, which is both important because core maintainer effort is the most precious resource in open source, and because it increases the likelihood that your PR will be accepted.

2. It makes it easier for people to use the history for analysis, which is especially important when you may not be able to speak directly to the original author.

These reasons also apply in commercial environments of course, but to a lesser extent.

For me, organizing my PRs this way is second nature and only nominal effort, because I'm extremely comfortable with Git, including the following idiom which serves as a more powerful form of `git commit --amend`:

    git add -p
    git commit --fixup COMMIT_ID
    git stash
    git rebase -i --autosquash COMMIT_ID~

An additional benefit is that this methodology doesn't work well for huge changesets, so it discourages the anti-pattern of long-lived topic branches. :)

> For that matter, why merge? Rebase it on top.

Yes, that works for me although it might not work for people who aren't going to the same lengths to craft a logical history. I have no interest in preserving my original WIP commits — my goal is to create something that is easy to review.

BUT... the PR should ultimately be merged with a merge commit. Then when you have a bug you can run `git bisect` on merges only, which is good enough.

> 2. It makes it easier for people to use the history for analysis, which is especially important when you may not be able to speak directly to the original author.

I've been on a maintenance team for ~5 years and this has saved me so many times in svn, where you can't squash, for weird edge cases caused by a change a decade or more ago. It's the reason I'm against blind squashes in git.

My favorite was, around 2022, discovering something that everyone believed was released in 2015, but was temporarily reverted in 2016 while dealing with another bug, that the original team forgot to re-release. If the 2016 reversion had been squashed along with the other bug, I might never have learned it was intended to be temporary.

I'm fine with manually squashing "typo" commits, but these individual ones are the kind where you can't know ahead of time if they'll be useful. It's better to keep them, and use "git log --first-parent" if you only want the overview of merges.

Someone did this to code meant to cut our web crawler bandwidth and someone didn’t notice it for like two years after it got toggled back off. So stupid. We were able to shrink the cluster after enabling it again.

I have an exactly opposite preference. Give me a big change to review. Going commit by commit or any imposed steps is not how I write code or how I understand code.

If you did not approach it through literate programming, I just prefer all of the thousands of lines at once.

Reviewing individual changes that may not even build properly is a waste of time; reviewing thousands lines of lines at once is also a bad idea.

Each unit of code (PR, commit, CL, whatever you want to call it) you send for review should be able to stand on its own, or at the very least least not break anything because it's not hooked into anything important yet.

You're in luck! For you, there is `git diff`.

(And for me as well — both the individual commits and the PR-level summary are useful.)

So, those of us who prefer commit-sized chunking don't have to do anything special to accommodate your preference.

It doesn't go the other way, of course, if you present one big commit to me. But so long as your code is well-commented (heh) and the PR isn't too huge (heh heh) and you don't intersperse file renamings (heh heh heh) or code formatting changes (heh heh heh heh) which make it extremely difficult to see what you changed... no problem!

> or code formatting changes (heh heh heh heh) which make it extremely difficult to see what you changed...

One of the "individual commits saved me" cases was when one of these introduced a bug. They tried to cut the number of lines in half by moving conditions around, not intending to make any functional changes, but didn't account for a rare edge case. It was in a company-shared library and we didn't find it until upgrading it on one of our products a year or two after the change.

One of the reasons I don't like a policy of "every commit must pass CI" is that I prefer to perform verbatim file moves in a dedicated commit (which inevitably breaks CI) with no logical changes at all, then modify code as necessary to accommodate the move in a separate commit. It makes review and debugging much easier.

This is my main use for branches or pull requests. For most of my work, I prefer to merge a single well-crafted commit, and make multiple pull requests if I can break it up. However, every merge request to the trunk has to pass CI, so I'll do things like group a "red/green/refactor" triplet into a single PR.

The first one definitely won't pass CI, the second one might pass CI depending on the changes and whether the repository is configured to consider certain code quality issues CI failures (e.g., in my "green" commits, I have a bias for duplicating code instead of making a new abstraction if I need to do the same thing in a subtly different way), and then the third one definitely passes because it addresses both the test cases in the red commit and any code quality issues in the green commit (such as combining the duplicated code together into a new abstraction that suits both use cases).

You are model citizen with those file moves. Totally agree with how that can be very disruptive for legibility and comprehension of changes.

Also for a year from now when I’m wondering wtf I was thinking when I put that bug into the code. Was a thinking of a different corner case? Or not at all?

> Can someone explain why anyone would want non-squashed PRs? > > For the 5% of engineers that diligently split each PR into nice semantic changes, I suppose that's nice. But the vast majority of engineers don't do this.

I think cause and effect are the other way around here. You write and keep work-in-progress commits without caring about changes because the history will be discarded and the team will only look at pull requests as a single unit, and write tidy distinct commits because the history will be kept and individual commits will be reviewed.

I've done both, and getting everyone to do commits properly is much nicer, though GitHub and similar tools don't really support or encourage it. If you work with repository history a lot (for example, you have important repositories that aren't frequently committed to, or maintain many different versions of the project) it's invaluable. Most projects don't really care about the history—only the latest changes—and work with pull-requests, which is why they tend to use the squashed pull request approach.

It’s mostly because pull requests are what is being tested in CI, not individual commits. Might as well squash as nobody wants to deal with untested in-between crap.

If you mean stacked PRs, yeah GitHub absolutely sucks. Gerrit a decade ago was a better experience.

> Might as well squash as nobody wants to deal with untested in-between crap.

I would rather deal with nice and tidy but untested commits rather than a very well-tested but too monolithic squash. If you test the eventual merge then you have done no less testing than the squash case.

Old commits are read more than they are run.

That's a problem with your CI. You can configure it to test all commits which make up the PR.

My CI takes 20+ mins and costs meaningful $ per run. Not happening.

> That's a problem with your CI.

Yes, but not in the way you think.

> For the 5% of engineers that diligently split each PR into nice semantic changes, I suppose that's nice. But the vast majority of engineers don't do this.

Here's a simple reason: at my company, if you don't do this, you get fired.

This is basic engineering hygiene.

Yep.

Those 5% shouldn't be approving PRs without it.

Those 95% shouldn't be code owners.

Nice things can be had, you just have to work for them.

> For that matter, why merge? Rebase it on top. It's so much cleaner. It's atomic and hermetic.

With an explicit merge, you keep two histories, yet mostly care about the "main" one. With rebase, you're effectively forgetting there ever was a separate history, and chose to rewrite the history when "effectively merging" (rebasing).

There's value in both, mostly seems to come down to human preference. As long as the people that will be working with it agrees, I personally don't care either way which one, granted it's consistently applied.

Rebasing is slower in practice to trunk based development and CI, while merging and squashing are moving farther away.

You can squash after rebasing or merge a PR without squashing.

I have always been very careful with git histories and often rewrite/squash them before final review/merge. Often my rewritten histories have nothing to do with the original history and commits are logically/intuitively separated and individually testable.

That said, very few people seem to be like me. Most people have no concept of what a clear commit history is. I think it's kind of similar to how most people are terrible written communicators. Few people have any clue how to express themselves clearly. The easiest way to deal with people like this is to just have them squash their PRs. This way you can at least enforce some sanity at review and then the final commit should enforce some standards.

I agree on rebasing instead of straight merging, but even that's too complicated for most people.

> Each PR being squashed to 1 commit is nice and easy to reason about. If you truly care about making more semantic history, split the work into multiple PRs.

I don't argue with your point (even if I am obsessive about commits separation), but one needs to keep in mind that the reverse also applies, that is, on other end of the spectrum, there are devs who create kitchen-sink PRs which include, for example, refactorings, which make squashed PRs harder to reasons about.

> Can someone explain why anyone would want non-squashed PRs?

So you can differentiate the plumbing from the porcelain.

If all the helpers, function expansions, typo corrections, and general renamings are isolated, what remains is the pure additional functional changes on its own. It makes reviewing changes much easier.

> If you truly care about making more semantic history, split the work into multiple PRs.

This exactly - if your commit history for a PR is interesting enough to split apart, then the original PR was too large and should have been split up to begin with.

This is also a team culture thing - people won't make "clean" commits into a PR if they know people aren't going to be bisecting into them and trying to build. OTOH, having people spend time prepping good commits is potentially time wasted if nobody ever looks at the PR commit history aside from the PR reviewers.

If I have a feature branch, and as part of that feature change, I did a simple refactor of something, I definitely want that committed as two separate commits in the PR, because you can look at the changes in isolation and it makes them a LOT easier to follow. And if you prefer, you can look at the diff of the entire PR in one single view. I don’t see the downside.

And please do not come back with “you shouldn’t do a refactor as part of a feature change.” We don’t need to add bureaucracy to avoid a problem caused by failure to understand the power of good version control.

This bureaucracy has very low overhead. Squash-merge the feature and then the refactor, or the refactor then the feature. Also makes reviewing each quicker.

Requiring me to do those changes in series as separate merges is the bureaucracy.

There is a reason pull requests and merges operate on branches, not just individual commits. It’s like you’re intentionally hamstringing yourself by saying these things must appear as a single commit.

Do I want every PR to be a long ugly list of trivial half-done commits with messages like “fix typo” or “partial checkpoint of encabulator functionality”? No. Does everything need to be hammered down into a single wad? Also no. There is a middle ground and people should be trusted to find it, and even to have their own opinion on where it is.

> Do I want every PR to be a long ugly list of trivial half-done commits with messages like “fix typo” or “partial checkpoint of encabulator functionality”? No. Does everything need to be hammered down into a single wad? Also no. There is a middle ground and people should be trusted to find it, and even to have their own opinion on where it is.

IMO `git merge --squash` was perhaps a cultural mistake. Few people use that command but the apparent cultural impact seems to have been great (if that was where it came from).

GitHub squash is a bullet list of all the commit messages. That’s just inviting a ball of mud changelist[1]. But because of the all too convenient "squash" shorthand we now have to explain every time: Yes, there is a middle ground between having one monolithic commit and keeping every little trivial checkpoint and correction.

[1]: The change: the diff. The list: try to correlate each bullet point with something in the diff. (In cases where that applies, some things will have been done and undone and won’t show up in the diff.)

the feature isn't ready for merge when the refactor happens ....

> having people spend time prepping good commits is potentially time wasted if nobody ever looks at the PR commit history

Good habits make good engineers.

You never know which of your commits will cause a future problem so structuring all of them well means that when you need to reach for a tool like git bisect then your history makes it easy to find the cause of the problem.

It takes next to no extra effort.

Making human-readable commit history is not that hard with a little practice. It's one of the big benefits of tools like magit or jj. My team started doing it a few weeks ago, and it's made reviewing PRs substantially easier.

+1: EdaMagit has been a game changer for me wrt reordering commits, fusing them together, and writing at least 1-2 sentences of proper commit messages after the fact.

If you ever worked with stacked PRs, and the top one gets squashed and merged it often becomes a nightmare to rebase the rest of the PRs to bring them up to date.

I wish this was easier. I have a workflow that I use to create stacked PRs which involves changing the target branch of the next PR to `main` after merging its predecessor, but it is too fragile to institute as a policy.

However, this is also just a more specific version of the general problem that long-lived, elaborate topic branches are difficult to work with.

jj makes this mostly trivial - well worth checking out if you’d like to work this way, but GitHub gets in the way.

    git rebase --onto squashed nonsquashed next-pr

Works fine in my experience (except when submodules are involved)

git merge --no-ff

git log --first-parent

git bisect --first-parent

The above gives you clean PR history in the main branch while retaining detailed work history in (merged) feature branches.

I really don't understand why would I squash having git merge --no-ff at my disposal...

+1, I have `git merge --no-ff` and `git pull --ff-only` set in my global gitconfig[1].

[1] https://github.com/rectang/dotfiles/blob/master/gitextra#L11...

Hoo boy is it fun to figure out where things went wrong when the real commit history was thrown away to make it look prettier. Especially a mistake from a merge conflict.

I had to stop two devs from fisticuffs. One of them used merge and manufactured a bug in the other’s code and was making a stink about it in the middle of the cubicles.

Merges lie I worse ways than rebase does. Hands down. With rebase I break my own shit. With merge I can break yours. Since your code is already merges into trunk, it has fewer eyes on it now and it’s on me to make sure my code works with yours and not vice versa.

I don't follow. In either case two branches are combined into one:

With a merge commit anyone can see each original path, and the merge result (with its author), and even try the three-way merge again. With a rebase, the original context is lost (the original commits were replaced by the rebased versions).

A rebase is a lossy projection of the same operation. A rebase lies about its history, a merge does not.

Merge with conflicts can be resolved with changes in code that don’t belong to the person who resolved the merge, and are not attributed to the person who resolved the merge. Git blame shows someone else as the person who introduced the bug. When you do a rebase you’re only modifying your own commits, or those of someone sharing your branch.

I'd really like to see an example of what you mean. Are you saying a git blame is attributing code to a person who did not write that code?

Are cherry picks involved (which also screw up history)? https://devblogs.microsoft.com/oldnewthing/20180313-00/?p=98...

Why would you want to restrict yourself to a one-dimensional mentality of commits when the source control system handles two-dimensions naturally and well? It seems to me a bit like wanting to only use about half the tools that you have available.

Squashes and Rebases delete information entirely out of source control. If a PR adds 100 lines of code, then deletes 50 of them and you squash it, you've lost 50 lines of code. Once your PR tool garbage collects those original commits you can't easily get it back. Maybe that's fine and that was garbage code anyway, but it was part of the process of getting those 50 lines you kept and could be relevant to questions of "why were these 50 lines added?" Were those other 50 lines alternatives that were rejected in testing, perhaps? Worse, were they deleted on accident in a bad inner merge and not caught in time?

I feel a lot less confident in the YAGNI code tossing that Squashes and Rebases do. I've had too many times where I've needed to code dive a fix out of a Merge commit or out of a long winding PR that went through several alternatives.

Git provides some great 2D navigation tools such as `--first-parent`. You can have "I just want a view of PR merges" and the structure of "the commits below that PR are accessible, too". I can't see why you wouldn't want that. That's what source control is for, "save all the minutia in case I need to find it again someday" and it is just a UI problem if you don't want the 2D view by default.

I think the "subway diagrams" that most git UIs show look pretty, especially in screenshots, but are not the UI most people actually want to work with day-to-day. I think a lot fewer people would be so adamant about squash-only or rebase-only workflows if more git UIs took a "1D" first view of the git DAG instead of "subway views". I think more git UIs should start with `--first-parent` and provide drilldown into "lower" commits instead.

I would definitely neither accept a pull request where the individual commits were testing and iteration, nor a pull request with hundreds of lines of changes are in a single commit. (New code, maybe.) It's not about ceremony; it's about knowing what changed and why.

I manage a team of developers, and I don't think any of us squash commits, and I really don't care. It's been working fine for 8 years at this job.

We keep our git use extremely simple, we don't spend much time even thinking about git. The most we do with git is commit, push, and merge (and stash is useful too). Never need to rebase or get any deeper into git. Doing anything complicated with git is wasting development time. Squashing commits isn't useful to us at all. We have too much forward velocity to worry that some commit isn't squashed. If a bug does come up, we move forward and fix it, the git history doesn't really figure into our process much, if at all.

Squash is just something you do at the point of merging. It's a single option during the merge and doesn't have you doing any more work than a merge that you don't squash. I don't know about github, but I know in gitlab it's a simple checkbox in the merge request (and it can be set to be checked by default by the admin if they want).

That's great for you, but squashing commits doesn't do anything for our team. It hides somewhat useful information, which never seemed like a good thing to me.

Other teams at my company are obsessive about squashing, and I am glad I don't work on those teams. They are frustrating to work with, they are notoriously slow to ship anything, and their product still breaks even with all their processes and hurdles to getting anything shipped. Teams that demand squashing simply don't impress me at all.

I'd take fully squashed PRs over endless "fix thing" and "updated wip"... but if you work in a way that leaves a couple meaningful commits, that's even better. Sometimes I end up in this state naturally by having a feature branch, which I work on in sub branches, each being squashed into a single final commit. Or when the bulk of the logic is on one commit, but then a test case or two are added later, or a configuration needs changing.

I like merge commits because they preserve the process of the review.

> I like merge commits because they preserve the process of the review.

I appreciate that, but I still can't square it with my world view.

GitHub or whatever tool you use preserves all the comments and feedback and change history if you ever need to go back and reference it. Such instances are limited, and in my experience it's mainly politics and not technical when this happens. The team's PR discussion itself isn't captured in git, so it's lossy to expect this type of artifact to live in git anyway. It's also much less searchable and less first class than just going back to GitHub to access this.

Ultimately, these software development artifacts aren't relevant to the production state of the software you're deploying. It feels muddled to put an incomplete version of it into your tree when the better source of truth lives outside.

Usually the merge commit is what has the link to the PR/MR. So it's the best way to actually find it.

> Ultimately, these software development artifacts aren't relevant to the production state of the software you're deploying. It feels muddled to put an incomplete version of it into your tree when the better source of truth lives outside.

You could make the same claim about the entire history. Git is a development tool, production just needs a working cut of the source.

What you have there is people hiding their neuroses and lack of commit hygiene and that’s avoiding the problem not fixing it.

I wrote a text about that:

https://lucasoshiro.github.io/posts-en/2024-04-08-please_don...

The question as stated answers itself. Some are able to make nice multi-commit PRs. So they do.

`git bisect --first-parent` lets you easily restrict to just the "PR level" if you are using PRs with merge commits (ie, no-fast-forward).

> with full history you can find the true code-level inflection point.

"typo fix"

“tues lunch wip”