[tomjakubowski]

I really don't like this. The code I write between commits is my thinking. I think by writing some code out, deleting it, writing again. The code I write that's shipped in commits is written for others to understand, and is a product of that writing for thinking process.

I don't want my thoughts to be serialized, version controlled and publicly accessible.

https://www.nature.com/articles/s44222-025-00323-4

[lwyrup]

I think they’re mostly considering AI agents. It’s an interesting idea (that I’ve seen before). Everyone trying to reinvent for AI which is fun!

But I am skeptical because just create a text file and put a reference to the commit.

Also, why not just use Fossil? It already lets you bundle whatever in there since it’s an SQLite database. It has all kinds of things built in that can reference commits.

[subygan]

This was my problem with JJ as well. I don't want everything in between to be versioned. I'm not even sure, every intermediary state between a commit is relevant or useful.

but feels like, I'm in the minority.

[steveklabnik]

To be clear, while jj does that, it's entirely local on your machine, and not shared.

[subygan]

Even on my local, that level of snapshotting adds unneded complexity that has very little value.

[steveklabnik]

Value is of course subjective, but many of jj’s popular features, like undo, are based on this.

(I actually think it’s tremendously valuable for a number of reasons but it’s fine to simply disagree about that.)

[soulbadguy]

Additional complexity ? jj just increase the frequency of snapshots. it does not fundamentality the complexity of the system

[skydhash]

The one thing I do like about git’s staging area is that it’s truly useful for reviewing a bunch of changes (bulk actions or automated tools). Go over the change chunk by chunk and stage what matters (magit makes that extremely quick.

That could be probably done by jj. But the git’s way is already fine for me.

[steveklabnik]

Yes, jj does make this very nice and easy. It’s the same idea as git, except that “the index” is just another anonymous change, not a distinct feature.

[eddd-ddde]

The internal version at least is heavily based on a global commit cloud.

If you give me your commit ID I can immediately print it on my workspace without you having to upload a formal change request.

[steveklabnik]

That’s a feature of jj’s integration with Piper, and is not relevant outside of Google, as neither Piper nor that jj integration is available to anyone else.

[soulbadguy]

I felt the same for a while after switching to jj. I think using the word "commit" in jj is creating a lot of confusing. The snapshotting is closer to auto-save in your favorite editor. In does not change your ability to version and save your work. It's just a savety net for quick undo

[steveklabnik]

It is called that because it is literally a git commit. jj might change it to “revision”, though, we’ll see.

[hinkley]

This is why I use rebase before PRs, and despise squash. You are not going to remember why you wrote that code that way 2 years from now and all we'll have to understand bugs and identify Chesterton's Fence situations is the deltas and the commit history. If you squash them I have 400 lines of code you 'wrote' all at the same time and only have the feature request it was assigned to as context. Thanks for nothing.

The worst actor would write a new module and check nothing in until it kinda worked. I think it went along with the fragile ego that had people sneaking around fixing bugs in his code without talking to him about it first. He wrote convoluted code that exhibited Kernighan's law and he was about 10 years too senior to still be doing that shit. He bragged about how 'powerful' his code was as if that was a compliment instead of a harbinger. Many times I found bugs in code from the initial commit. Just... give me something man. Anything. Fuck.

Just because you tried random shit until you found the problem doesn't mean you have to fess up to it. You can tell any story you want that gets us from point A to point B now that you know point B is attainable. You can rearrange the commits the way you would have written it if you knew exactly what needed to be done. Drop 90% of the code you wrote and immediately deleted again, anything that doesn't support that narrative.

In law enforcement you have something called Parallel Construction. You can know a suspect is guilty by knowing facts that are not admissible in court. So you need to rediscover those same facts by the book. Grab his trash on trash day. Interview neighbors. Get enough circumstantial evidence to get a search warrant, then go find that evidence again.

[crimsonnoodle58]

We're the opposite. No rebasing your PR. It changes the hashes which we use for ci/cd. Keep it linear, show me the full history, show me where you merged main back into it, and then we force squash on merge.

Main then has a nice single commit with a reference to the branch it came from if you wish to see how it developed. Why would we want to litter main with your 100 commits? You own your code, and if you wish to dig into why you did something in a commit, go look in your branch history.

[hinkley]

> Main then has a nice single commit with a reference to the branch it came from if you wish to see how it developed.

Yeah sorry that's a toy project. You have 50 people push commits for six years and see if those branches don't 'accidentally' get deleted. We need a different VCS tool to get what you're after there.

[giraffe_lady]

Probably coulda used an example that isn't itself a fourth amendment violation that essentially requires perjury to accomplish. Also less euphemistically called evidence laundering. Not really a neutral example.

[bonzini]

A more charitable case is that the source cannot be disclosed because it's an undercover agent or informant. What the parent describes is indeed evidence laundering.

[hinkley]

I was in fact thinking of informants but was a bit fuzzy on my facts so I demured. Sorry it came out a bit of hashed.

[jimbokun]

So are you going to go out and commit a crime because a random person used a crime as an analogy?

[giraffe_lady]

I’ve done it over less.

[hinkley]

If I look in your back yard right now, will I see a stolen giraffe?

[sharts]

Squash smaller commits?

[hinkley]

If it's part of the rebase. If commit 3 in the chain doesn't compile and half the tests fail, that's not very useful for someone trying to figure out how an ancient bug nobody noticed for a year got into the code. If commit 4 fixes it, then 3+4 -> 3.

But if you add a function in commit 2, then realize three hours later than you just need to call another function, I don't need to see the function arrive, get used, half the tests written, the whole thing be deleted, and then a couple commits that do it the easy way and only needs 3 tests added.

That fakeout will be in the code tree forever and each new dev who is trying to grok the code will see that the line of whitespace on line 35 came along with a function that doesn't exist anymore and only really ever did on David's machine.

[skydhash]

Squash and merge (if that’s what you’re talking about) is only useful in a pr context. Each PR would actually be a commit if you we using the git-email model. Commits inside such PR are just snapshots.

[bmitc]

> This is why I use rebase before PRs, and despise squash. You are not going to remember why you wrote that code that way 2 years from now and all we'll have to understand bugs and identify Chesterton's Fence situations is the deltas and the commit history.

This forces people to work in a very linear fashion that doesn't match how people actually work.

A 400 line commit from a squashed PR should be very manageable when tracing a bug in the main branch, especially if the PR has a good description and review. Having a bunch of "fixed, added, deleted" commits all pushed into main seems like a disaster of noise unless you now force everyone to bundle perfectly reversable actions in every commit.

[hinkley]

> "fixed, added, deleted"

I'm saying get rid of those before you invite people to look at the code. Keep the 'code review changes' one because that's comedy gold when the PR changes forced on you by some snowflake actually cause a production outage at 2:00 am.

[Joker_vD]

> Having a bunch of "fixed, added, deleted" commits all pushed into main seems like a disaster of noise unless

unless you skip non-merge commits when reading the history of main. And personally, I don't remember needing to read main's history more often than probably once a year, and even then mostly out of curiosity.

Also: having a bunch of "ticket resolved" commits all pushed into main seems like a disaster of noise, compared to simple "release 203", "release 204", etc. series of commits that comprise the main. Squash even further! Just as you don't need to track every small development change inside a feature request, you don't need to track every small feature or fix inside a full release. Right? You write a changelog (if you even write them) using those 400 merge-commits, then squash it into a one commit for you release, bang, clean history.

[hinkley]

[delayed]

[jeremyjh]

Also - at least in GitHub if you squash with the PR merge action in the UI - the original commit history is still available in the ref maintained by the closed PR yet doesn’t clutter your branch or tags namespace.

[fridder]

The collaboration part I’m skeptical of but I get it, as it sounds like a feature made for business consumers

[sdesol]

This sounds like it is more aligned with what I have created which is "We need to capture your conversations with AI". If you look at

https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r...

you can see that every file has a code block header with a UUID and the AI that was attributed to it. With the UUID, I can tell exactly how the code came about.

What they are working on will be more useful for AI code provenance. It is only a matter of time before you are expected to show your chats with AI as part of the code review and for performance reviews.

So I don't see human collaboration being the main use case. I see tracking, studying and improving the Human-AI relationship...and seeing if somebody should be promoted or not.

An interesting take I've heard is, we will have a token/impact stat where if you spent a shitload of tokens to produce the same impact as somebody else who spent a lot less, you will be the prime candidate for layoffs and/or less pay. This is why I think AI code provenance will become a serious thing in the future.

[selicos]

Audit purposes for sure. How was this code/concept generated, what were the prompts/requirements, what thinking did the model complete, can this be replicated or repeated, etc.

A vendor conference I was at a few weeks ago focused heavily on this, for most of their Agentic workflow items. How can you show the AIs work, prove what it did was within guidelines, then audit the process and result.

Like, if your system has an AI backed federated search for documents and you ask it a question about those documents, you need an audit trail of the ask, what documents were referenced, and what was returned to the user.

Then if wrong information was supplied that can be pinned down and explained in case of lawsuit or other need.

[jorl17]

FYI your link 404s.

Seems like you copied the ellipsified version, so what we get is https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r

[sdesol]

Fixed, thanks!

[jcgrillo]

Fully agree, very icky surveillance vibes. In particular:

> DeltaDB breaks your work into a stream of fine-grained deltas. Where Git captures a snapshot at each commit, DeltaDB captures every operation in between and gives each one a stable identity.

I was curious about giving Zed a try, now that it has an emacs keymap. Not anymore. This is such a horribly invasive feature, I absolutely do not want my colleagues reviewing every single intermediate edit, down to the keystroke, that went into the commits I publish for review.

Before I put a PR up for review, I'll sometimes edit my commit history a little bit in magit to make it more linear and digestible--maybe update descriptions, squash some adjacent commits together, etc. This just throws that whole aspect of the job out the window and says "hey, colleague, hoover up this firehose of deltas and enjoy it".

And what the hell does this even mean?

> What we're really after is simple: the conversation with the agent becomes the only conversation you need to have.

Lmao. No. Wrong.

[fridder]

The more I think about it and your comment the more I wish it was local only. It could be useful to analyze your editing habits and interactions with AI but I want that for my own benefit not random coworkers

[slackpad]

Yeah I really would not want all my convos synced up like this. I've been working on a personal version of something like this but it keeps all your conversations and notes in a separate Git repo that you control that's totally separate from the project repo - it's entirely designed for personal use:

https://github.com/modulecollective/moe

[jcgrillo]

I would probably only use these data if I had some script I could run in it for analysis, and even then optimizing my AI chats is probably pretty low value.. certainly not enough to justify the cost of analysis, unless there's something that provides actionable insights with almost zero time investment.

Producing code edits itself is such a small fraction of the job I'm really not convinced these are valuable data. Mostly the effort and time goes into reading and understanding code, not producing or transforming it.

[selicos]

This seems like a perfect audit feature to flip back and train a model. Or ensure your human worker is working during business hours.

[bmitc]

Yea, commits that go into a PR are generally just a sequence of logs and not necessarily a sequential stream of explicit steps.

[0xb0565e486]

Aren't you paid to think?

[xboxnolifes]

This cannot be the counterargument to every post that basically says "The employer shouldn't be able to access, collect, serialize, and own every breath I take". It's too unserious.

[pdimitar]

No, you are paid to deliver. Whether you do that by thinking + hand-coding or just vibe-coding, or handing the task description to Cthulhu and waiting for him to materialize the solution on your disk, is immaterial.

Unless of course you also have to explain your thinking and problem-solving process in meetings, which happens quite a lot the more senior you get.

[NewJazz]

A woodworker is paid to work with wood. But the finished product is the worked wood, not a detailed summary of how the wood was worked with.

[bauldursdev]

No I'm paid to write code.

[malyk]

No, you are paid to provide solutions for your customers.

[NewJazz]

Does that... Not imply thinking avout what you are writing???

[oriolid]

Everyone probably has thought "what was the person thinking when they wrote this". Now you know that they probably didn't think (and since 2025 or so, it might not even have been a person).

[muadddib]

and you can do that without thinking?

[gmueckl]

Don't be afraid to show your thoughts when asked to. The best developers are those that can express their thoughts clearly at any stage throughout their process. This is one of the skills that shows to me the level of experience a developer has.

[MaulingMonkey]

I don't want the private API key I temporarily hardcoded in my public history. Nor do I want the drag of worrying about so much as sneezing in the general vicinity of a secret in my editor window, when I already self review before commit.

I don't want the unkind rant about a coworker's design as I attempt to figure out what they were smoking when they made the thing I'm trying to use, needlessly offending them. For starters, once it clicks, it might all make sense, and have turned out to be my mistake. For another, even if a rant is warranted, a pass for "tact", or at least limiting the blame to the blame that is warranted, is proper.

I don't want to drag a coworker through my chain of confusion until I've made an appropriate amount of effort to unconfuse myself first. To do otherwise is likely to bring us both to confusion, possibly in different ways, possibly including confusion about what we're confused about, which is just a mess and dead weight. There's a time and place to explain and teach, and a time and place to expose my own confusion and ask for help, but neither is step 1.

Even if the API is undocumented and confusing, even if you're expected to ask for help as step 1, there's value in a fresh set of eyes getting a feel for exactly how the API is confusing before that, thus informing directions for potential improvement (be that API changes or improved documentation.)

[gmueckl]

I'm not advocating committing secrets to version control.

But you can learn to phrase your WTFs about your colleague's code politely and constructively. I would even argue that this an absolutely basic skill for professionals. It typically leads to faster and better answers whenever a discussion arises.

Even if confusion seems to spread in a discussion, I would expect the person who realizes this first to call that out and and to reset the conversation.

There is nothing magic or onerous about this.

[InfinityByTen]

One of my professors in undergrad said: the most dangerous mathematicians are the ones that begin the proof with "Consider a case ...". He said that these mathematicians are the ones who don't share anything about how they got the case and they end up projecting this sort of "magician aura". I don't know how accurate that assessment it, but I think it captures something that never sat well with me.

In my life, I've never liked people who deliberately polish up their articulation to the level that it obfuscates how they arrived at that understanding (whether it's academics or engineers). They might not do it for attention and they might not be doing it knowingly. IMO, they are taking away the opportunity of learning from the people they are talking to. For me the conversation is one sided. I'm there to listen, but rarely can I ask questions, give feedback or grow from where they have possibly reached.

[ozim]

Ugh, let's take a step back and make a distinction:

I don't need your fluff. No one cares how you arrived writing another crud line to save an object to database or sent yet another AJAX call.

If you wrote some genuine great compression algorithm that's a different take on compression, I would like to see step by step reasoning and eventual dead ends.

[InfinityByTen]

I shared my thoughts in the context of someone saying that one should be able to share your line of thinking when asked to. Whether "when one asked to" applies to keystroke by keystroke blockhained versioning isn't my point of discussion.

I get it, that the overall discussion is about DeltaDB. I'd say interesting concept to toy with. I'd pay more attention to "micro commits" as the idea more than the keylogger.

[8note]

why this particular object though?

why didn't you add these three other parameters to it?

how does this default value make sense when unset?

mostly things that end up not-in-the-commit that 3 years from now people are gonna wonder about is really handy to know

[jimbokun]

I strongly doubt that.

[hinkley]

I think a good argument ad absurdum for this is to look at how some recipe sites give the entire genealogical history of the author and an anecdote about how their gammy met Theodore Roosevelt and he stole her pen. Three pages later I discover I need to go to the grocery store because the recipe requires sour cream. And the store is closed so I need a different recipe.

Don't fucking do that. Do something way less than halfway to that line.

[jimbokun]

Agree on the software case. Disagree about the recipes.

Food writing is its own genre where the recipe is one part of a larger story. Can often include travel stories as well.

Maybe not your thing. But definitely has its place.

[hinkley]

"So I was thinking about #####'s Law this morning, and I realized that #######'s Theorem might apply if we do this and ignore that. Then I went up a blind alley and stopped for coffee and realized I was overcomplicating it, we don't care about negative or imaginary solutions."

They don't need to know I was brushing my teeth and thinking of bacon and an argument I had with my spouse right before I thought that though. Or how rude the customer in front of me was to the new barista who was just trying her best.

[rdedev]

The example I had was of Ramanujam. "It was revealed to me in a dream"

[hinkley]

I love that man, and I hate that man. For many of the reasons already listed in this thread. He is smarter than Feynman, but also dumber than Feynman.

[ablob]

I personally stumble upon many topics where I only care about the what. In that case all the theory is just a distraction I'm just wading through to get to the point. If it's optional, then looking into the how and why is certainly nice, but it should be part of an appendix or a commentary and not interspersed within the proof unless an uncommented version exists.

[jcgrillo]

OTOH polishing up the presentation can really improve the experience of a first-time reader of the work (e.g. your code reviewers). If the polishing is done with good intent and proficiency you can make something that was very convoluted and difficult to arrive at digestible with far less effort. It also aids your own understanding: "If we can reduce it to the freshman level that means we really understand it" (or similar I didn't look up the exact quote, attributed to Feynman). If you're polishing something up to make it understandable that's totally different than polishing it up to make yourself seem smart, right?

[hinkley]

Nobody needs to know quite how messy the process of making the sausage is though. There are steps that provide information, even about how the bugs got in there. But not every thought needs to be expressed.

[aeonik]

Disagree. This how people best learn from each other. It's also nice to audit your own thought process objectively.

It makes one vulnerable though, that's for sure. Psychologically I mean.

[jimbokun]

Maybe the person reviewing your PR is too busy to also provide therapy for your internal thoughts while writing the code?

[hinkley]

I cook my own commits 75% for me six months from now and 25% for everyone else. I'm literally only doing about 1/3 more work (on the therapy part) than I would have done anyway.

[aeonik]

People barely read PRs at most places I've worked.

The only reason they'd go deeper is for a bisect, or some other analytical method.

At least one day I hope they level up to be able to do that.

It's a golden rule thing for me.

I like more information because it's easier to filter too much data, than to reconstruct destroyed information.

[hinkley]

Whether you realize it or not, you're insisting all the neurodivergent people at your job unmask themselves, and fuck that noise.

[aeonik]

I'm nuerodivergent, I dream of a world where not only can they unmask, but that normal folk will see the intricate chaotic beauty behind it.

Probably a pipe dream though.

But for sure I don't want to force it on people.

Don't use the feature if you don't want to, I'm all about freedom of choice.

Just saying the upside to it.

[8note]

health inspector is a literal job that needs to know how messy the process of making the sausage is, so they can enforce health standards so nobody gets sick when eating it.

if you're calling what you're doing engineering, you are following a standard best practice, and should easily be able to run through a checklist and show your work at each step.

not every thought needs to be expressed sure. its irrelevant what you thought about your lunch. Its important how you picked what latency numbers are important, and how you went about predicting volume, including what factors your did and didnt look at.

software developers havent been rigourous engineers over the last several decades, and that isnt a good thing

[hinkley]

No arguments here. The weird thing is that this was all much more straightforward when we did trunk-based development. You still ended up stashing four different things and having multiple speculative local branches while you tried your crazy ass ideas out, and Mikado Method was your very best friend.

What ended up happening is you committed the safe bits and the reversible decisions first to buy yourself time to work out the tricky bits before you had to commit (literally and figuratively).

I think trunk-based development is greater than PRs, but the values are close enough that the politics of PRs (specifically, consensus-based development) win out, or at least aren't worth fighting.