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

141–150 of 230 posts

Re: Software is made between commits

#141

Post by jimbokun »

gnunicorn wrote: post #65

I totally see where they are coming from, jitsu, too is making every change its own artifact. And it plays hard to the "faster shipping" that especially AI-driven teams are pushing hard, and find the review process to be the next big bottleneck now (as I just saw with my last client as well). There has also been a lot of discussion about the value of the peer review process recently, in in general. But I wonder if th…

I often find it helpful to see the entire commit and message leading to a specific line of code getting into its current state.

That’s about it.

Re: Software is made between commits

#142

Post by jimbokun »

ChrisMarshallNY wrote: post #9
hyperhello wrote: post #3

I hate software tools now. I really do. A hammer would never ask you to think about it constantly. If you think about your hammer it’s because something is wrong with it.

It's not just tools. Pretty much all software is like that. The problem is, is that it works, if you assume "working" means the software sellers get wealthy. There's a reason that most waitstaff wear black. They should blend into the background, and not be what the folks at the table are talking about. In rare instances, restaurants exist, where the waitstaff is the service. In software, though, you're being served b…

My favorite new-to-me cathartic feature is Safari’s hide distracting items.

Probably easier with an ad blocker or just Reader view. But I really enjoy tapping on all the overlays and moving ads and videos and see them evaporate one by one, leaving just the text I wanted to read.

The default state of the page is much like the restaurant you describe.

Re: Software is made between commits

#143

Post by Joker_vD »

bmitc wrote: post #123
hinkley wrote: post #53

Earlier quoted context omitted.

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. Th…

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

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

Re: Software is made between commits

#144

Post by subygan »

steveklabnik wrote: post #104
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.

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.

Re: Software is made between commits

#145

Post by eddd-ddde »

steveklabnik wrote: post #104
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.

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.

Re: Software is made between commits

#146

Post by soulbadguy »

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.

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

Re: Software is made between commits

#147

Post by soulbadguy »

subygan wrote: post #92
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

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

Re: Software is made between commits

#149

Post by isityettime »

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

Post reply on HN