I don't want my thoughts to be serialized, version controlled and publicly accessible.
but feels like, I'm in the minority.
(I actually think it’s tremendously valuable for a number of reasons but it’s fine to simply disagree about that.)
That could be probably done by jj. But the git’s way is already fine for me.
If you give me your commit ID I can immediately print it on my workspace without you having to upload a formal change request.
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.
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.
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.
The main branch remains compact with a linear history without the commit noise. Deleted branches can be restored, commits that otherwise do not exist in the history can be interacted with, and so on.
But I agree on not rebasing PRs. Another benefit to avoiding force merges is that it's easier for reviewers to compare changes since their last review.
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.
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.
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.
You're probably delegating that work to someone like me who actually figures out what the systemic problem is that caused the same class of bug to make it to production 5 times in the last 3 years. If you're a lead or a principal and still saying this ^ then you need to expand your skillset.
Bad luck doesn't happen very often. Mostly it's blindspots.
I will confess though that the sort of forensics I do is probably not divisable from the fact that I'm also the designated VCS surgeon on every project I've been on since 1998.
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.
We notice, we just reduce your trust level instead of confronting you. I can think of a lot of things that get bitched about over lunches or coffee much more often, but you're still being complained about.
> 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.
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.
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.
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.
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.
Seems like you copied the ellipsified version, so what we get is https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r
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.
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.)
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.
I see a fundamental difference between thoughts and whatever words I pronounce. You're saying "you should share your thoughts", and I disagree. My thoughts are mine. Whenever I want to share something with the world, I phrase it and share the result of that process.
Phrasing things politely and constructively is what I'm explicitly advocating for when I'm calling for "tact", yes. But said phrasing is not necessairly the very first thoughts out of my mind. When we push back on sharing our raw thoughts, it's precisely because we want a moment to be able to translate from passionate, driven, and perhaps rude thoughts - to polite, if perhaps a bit professionally dispassionate words. From unconvincing incendiary moral judgements against the cult of the singleton, to concrete examples of maintainence concerns and tradeoffs that can be discussed by everyone. From things that barely make sense in the context of our own minds, to things communicated clearly within the context and bounds of our shared understanding.
> 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.
Simply calling out confusion is insufficient to resolve confusion. Being able to narrow down what I'm confused about is an important skill and first step towards either unconfusing myself, or seeking help from others, allowing them to aid me in solving said confusion.
Unconfusing others is a step more difficult. Unlike with my own confusion, I find it necessary to build an accurate mental model of their thought process through my own indirect observation and questions, to understand where they've misunderstood, the correct understanding, and then a means of explaining and contrasting those two states through nothing more than clear communication to bring them out of said confusion. I may have to construct full blown examples, showing a concrete way their own initial biases fail them.
These are important skills and steps to take, of course, and you're right that there's nothing magic about it, but this is something I've expended a lot of time on over the decades I've been puttering around in development circles. It's time intensive, requiring one or more people focusing on a single individual's issues, just to reset things to a baseline of being unconfused enough to do good work.
And, of course, it will always be necessary, and I'm glad to help. It's a skill I believe I'm good at, and by unblocking coworkers and friends, I can potentially spend minutes of my time to save hours or even days of theirs, which is well worth it. But it's also worth taking the time to avoid such scenarios coming up again. It saves me time, and it saves them time.
Sometimes that means clearing up ambiguous or confusing documentation.
Sometimes that means keeping others at arm's length - at least until I'm at least no longer confused about what exactly I'm confused about.
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.
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.
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.
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
Don't fucking do that. Do something way less than halfway to that line.
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.
Maybe this is the mathematician's lament rejigged. And I have held it for probably 20 years of my life. I try to do things differently when I write, but I have to say there are enough people who find it sub-standard. It's too imprecise or ambiguous or not clear enough for their taste. They aren't wrong. But I'm not done learning and I start building my thoughts as I go along.
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.
It makes one vulnerable though, that's for sure. Psychologically I mean.
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.
I know I'm done with a module when people add features to it the way I would have done so. That sounds like a non-statement, but I bet if you watch your projects closely, you'll see that's often not the case and sometimes it's laughably bad. It goes along with Knuth's thing about code meant to be read by humans and incidentally by computers, and also Kernighan's Law. My code eventually just says exactly what it does. And I don't use the same noun to mean three different things in three different places. Why? Because then I can take my name off of the bus number list and pick something else up. This module that I wrote is Steve's baby now, and that one is David's. In fact taking it over is how David got promoted.
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.
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
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.