Is not steam exactly doing that and other vendors follow their footsteps?

I remember that a llm agents often store those in clear text files (I think claude-code beeing one of them). Many of the CLIs I use have a better secret hygiene than that i.e. allow passwords commands or use secret apis.

I am a human and I can't...

looks like you failed your last exam, please exit through the red door down the aisle.

Well the thing is, you have a copyright that you can license. However from what it currently looks like, fine-tuning/training is not copying.

Doesn't make any difference in practice. The debug info is never mapped into memory by the loader. This only matters if you want to store the two separate i.e lazy load debug symbols if needed.

this is just not true. I just tried with one of my binaries which is 3.2G unstripped, and 150MB-ish stripped. Unstripped takes 23 seconds until the window shows up, stripped takes ~a second

There is something wacky going on with your system, or the program is written in a way that makes it traverse the debug info if it is present. What program is it?

For example I can imagine desktop operating system antivirus/integrity checks having this effect.

It's ok actually. I have read some Windows code. Certainly better commented than Linux and certainly much more readable than glibc.

Wasn't a whole bunch of the NT source leaked ages ago?

You just need to look in the DDK (driver development kit) to see what it's like. Hungarian notation everywhere.

I can second that. If there are multiple commits: https://github.com/tummychow/git-absorb is handy to add formatting changes into the right commit after commits already happened.

It looks like git absorb rewrites history. Doesn’t that break your previously pushed branch?

That's a controversy I'm not sure you necessarily realise you've stepped into :).

It's fairly common to consider working and PR branches to be "unpublished" from a mutability point of view: if I base my work on someone else's PR, I'm going to have to rebase when they rebase. Merging to `main` publishes the commit, at which point it's immutable.

Working with JJ, its default behaviour is to consider parents of a branch that's not owned by you to be immutable.

My branch is mine. Don't tell me what I can or can't do. I push WIP stuff all the time, to share code with others for discussion, to get the build to run in parallel while I keep working or just at the end of the day. I freely amend and will squashed before merging (we only allow a single commit per branch to go to master).

If I or someone else bases something off anything but master that's on them to rebased and keep up to date.

My philosophy is that once a PR is open, that's the point at which people should no longer feel free to treat their branch as their own. Even in groups that squash commits, it should still preserve the aggregate commit messages.

But until that PR is open? Totally with you. There is no obligation to "preserve history" up until that point.

Strong disagree: until the branch is merged, it's mine.

I'm in a camp that prefers single rebased commits as units of change, "stacked diffs" style.

GitHub in particular was annoying with this style but is definitely getting better. It's still not great at dealing with actual stacks of diffs, but I can (and do) work around that by keeping the stack locally and only pushing commits that apply directly to the main branch.

Not to disagree, but this is so GitHub-centric. What is up with "diffs", "patches", and "submissions"? :D

Not to disagree, but calling it Github-centric is a bit over specific :)

I regularly work with Github, Bitbucket, and Gitlab. Everything I said applies except for the fact that I said "PR" instead of "MR". But yes, you're right. I'm highlighting a specific, albeit extremely popular, workflow.

I know, I know, I was going to edit it to "Git{Hub,Lab}" in the beginning but oh well.

In any case, my comment just reflects on the fact that you had a series of patches that you could not squash or rebase. It stuck.

And the fact that I see many people use the abbreviation "PR" for something that is merely a patch or diff. For example you might send a diff to the tech@ mailing list, but you should not refer to it as a PR.

GitPub

I think this fits the description well.

We work on GPU accelerated VMs, so that in future we can also bring NixOS + VPNs to desktops/end users to machines that don't run NixOS. We will use it as an application runtime where can control the whole stack. Just now we are mostly focused on managing distributed NixOS machines. The VPN helps to provide services on any kind computer, even if not running in a datacenter. You can read the description here for context: https://docs.clan.lol/

Maybe I'm in the same boat as people who didn't get docker before it was popular, but this seems really convoluted to me... is there really a market for this? Why do other existing things not solve this problem?

There is huge demand right now to create sandboxes for agents. VMs are one way, and Clan one solution for VM management.

Maybe they are not the right solution, but they are working on the right problem.

Of course, they don't say the focus on agents, but if the solution works with them, it doesn't matter that it was built for gamers.

git has rere, but jj doesn't because its equivalent is built in. https://github.com/jj-vcs/jj/issues/175#issuecomment-1079831... is some discussion about the differences here.