Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software is made between commits

zed.dev

Post reply on HN
Print view View original

151–160 of 230 posts

Re: Software is made between commits

#151

Post by gmueckl »

MaulingMonkey wrote: post #122
gmueckl wrote: post #49

Earlier quoted context omitted.

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.

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 s…

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.

Re: Software is made between commits

#152

Post by danpalmer »

isityettime wrote: post #149
Lindby wrote: post #82

All the things in between my commits is a messy soup. Looking there is not useful to anyone. I rewrite my history with git rebase so each commit is small and atomic. The story I create with my commits is what explains why things are as they are, it doesn't matter if it's the true chronological story on how it actually happened. I agree with the author that reviewing pull requests is too late. The problem with pull re…

> The problem with pull request is that they make it hard to review individual commits since they are geared towards reviewing the result of an entire branch at once. But the answer is not to share all the noise, it should be to encourage small atomic commits so you can review the early work before the entire feature/fix is complete. Isn't that just a GitHub problem, as opposed to Phabricator, Gerrit, etc.?

It is, but I think it's hard to explain to folks who have only used the Git/GitHub model – I know, I've been that person not really getting it.

I think what's missed is two things:

- In the Phabricator/Gerrit model you typically end up with changes that are smaller than a PR, but bigger than a commit.

- You lose some history, or track it in a different way. With a PR you might add code to address comments in a new commit on the end, but with Phabricator/Gerrit you don't. If you already aggressively rebase in Git to absorb changes into commits that they make sense to go in, this won't be much of a change, and some systems give you views on the history happening within each change. But if you expect to see everything like that in the Git history, you may not get that, but the workflow changes around it and that's ok.

I think both types of review are in a local maxima, where you lose some things to move to the other type, and it was fear of losing those from my workflow that made me resist the change a bit. When you get there though, you realise it's just not a problem.

Re: Software is made between commits

#153

Post by skydhash »

soulbadguy wrote: post #146
subygan wrote: post #144

Earlier quoted context omitted.

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

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

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.

Re: Software is made between commits

#154

Post by steveklabnik »

eddd-ddde wrote: post #145
steveklabnik wrote: post #104

Earlier quoted context omitted.

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

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.

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.

Re: Software is made between commits

#155

Post by steveklabnik »

skydhash wrote: post #153
soulbadguy wrote: post #146

Earlier quoted context omitted.

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

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.

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.

Re: Software is made between commits

#156

Post by steveklabnik »

subygan wrote: post #144
steveklabnik wrote: post #104

Earlier quoted context omitted.

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

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

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.)

Re: Software is made between commits

#157

Post by steveklabnik »

soulbadguy wrote: post #147
subygan wrote: post #92

Earlier quoted context omitted.

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.

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

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

Re: Software is made between commits

#158

Post by lwyrup »

tomjakubowski wrote: post #20

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

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.

Re: Software is made between commits

#159

Post by aeonik »

jimbokun wrote: post #131
aeonik wrote: post #99

Earlier quoted context omitted.

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.

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

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.

Post reply on HN