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

Cruller: Bun's Zig Runtime, Continued on Zig 0.16

ziggit.dev

Post reply on HN
Print view View original

71–80 of 127 posts

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#71

Post by taybin »

sevenzero wrote: post #48
Skywalker13 wrote: post #37

I don't understand why the git history has been pruned in this fork. According to the first commit in this fork: > Squashed as a single orphan commit — the original oven-sh/bun history isn't relevant to this stripped fork and its shallow clone doesn't push cleanly to a fresh remote. IMHO it's always a bad decision to do that. Here, all commit authors are lost. The original history is always relevant.

How is the history relevant? Honest question. 5 years in the field I never had a reason to check out the git history of any project I ever worked on.

There are several possible reasons for that, but I'll just say it's a very common use case. It's actually the one of the original use cases for SCSs. How else could you revert to a prior commit?

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#72

Post by cyberrock »

sevenzero wrote: post #50
cpuguy83 wrote: post #49

Earlier quoted context omitted.

Bug is uncovered. Where was it first introduced? Why was the code changed? What did it do before the bug was introduced?

Why would that matter if a bug is uncovered? If you know there's a bug just fix it? Like what use does the bugs history have?

Diagnosing why a bug happened is interesting. Sometimes it points to a communication shortcoming that the project/organization should strive to improve on. Of course, if you're slinging code with a few buddies, it might not matter.

In the worst/most paranoid case (xz) you might also want to know who planted a backdoor and where else they made commits to.

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#73

Post by skeledrew »

sevenzero wrote: post #50
cpuguy83 wrote: post #49

Earlier quoted context omitted.

Bug is uncovered. Where was it first introduced? Why was the code changed? What did it do before the bug was introduced?

Why would that matter if a bug is uncovered? If you know there's a bug just fix it? Like what use does the bugs history have?

Chesterton's Fence.

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#74

Post by vlovich123 »

sevenzero wrote: post #59
afavour wrote: post #52

Earlier quoted context omitted.

Because there will be a reason why the code was changed that introduced the bug. If you fix the bug you might inadvertently break a different piece of functionality. A git commit gives you the reason for the change and the context of what other files were changed at the same time. I’ve found that invaluable.

Guess I must be doing something wrong to never have encountered this issue in my 5 years.

You can of course choose alternate strategies. It comes up a lot when doing low level systems programming because the bugs can be non-trivial to repro and root cause (particularly for C/C++ where you have segfaults and whatnot). So it’s cheaper and faster to try a bisect to find the regression introduction as an additional clue in the root cause analysis (eg ownership rules changed or there were changes that looked correct regarding threading but when you hyper focus on it you realize what the problem is). Or you’re working on a high performance codebase and there was a performance regression - it can be faster to bisect than it is to try to find the issue with profiling tools (I had this and seen issues where profiling tools would never have told you the issue).

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#75

Post by pastakatsu »

sevenzero wrote: post #48
Skywalker13 wrote: post #37

I don't understand why the git history has been pruned in this fork. According to the first commit in this fork: > Squashed as a single orphan commit — the original oven-sh/bun history isn't relevant to this stripped fork and its shallow clone doesn't push cleanly to a fresh remote. IMHO it's always a bad decision to do that. Here, all commit authors are lost. The original history is always relevant.

How is the history relevant? Honest question. 5 years in the field I never had a reason to check out the git history of any project I ever worked on.

You've truly never come across a single thing you've gone to "fix" only to have it break stuff and then explained why it needs to stay that way in a commit message?

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#76

Post by loeg »

sevenzero wrote: post #59
afavour wrote: post #52

Earlier quoted context omitted.

Because there will be a reason why the code was changed that introduced the bug. If you fix the bug you might inadvertently break a different piece of functionality. A git commit gives you the reason for the change and the context of what other files were changed at the same time. I’ve found that invaluable.

Guess I must be doing something wrong to never have encountered this issue in my 5 years.

As you get better at engineering and grow into a senior, you'll find this more valuable.

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#77

Post by cscheid »

sevenzero wrote: post #59
afavour wrote: post #52

Earlier quoted context omitted.

Because there will be a reason why the code was changed that introduced the bug. If you fix the bug you might inadvertently break a different piece of functionality. A git commit gives you the reason for the change and the context of what other files were changed at the same time. I’ve found that invaluable.

Guess I must be doing something wrong to never have encountered this issue in my 5 years.

I'm just going to answer this one candidly. Yes, you are doing something wrong. Immediately: the commit history is useful to understand the context in which a bug was introduced, because it's the best context to understand the _reason_ the mistake was maybe, which is a really good way to prevent regressions. But more generally: when an entire industry has arrived at an accepted practice, you the junior developer (sorry, 5 years is _nothing_: you need to be told this too) have a chance to pick up on it.

Have you heard "have you played guitar for 20 years, or have you played guitar 20 times for a year?" Time only helps with accumulating wisdom if you let it.

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#78

Post by loeg »

flohofwoe wrote: post #11
pjmlp wrote: post #6

As usual, most forks created out of community rupture eventually die.

I think there are quite a few high profile examples where the fork was successful (egcs comes to mind which eventually became the official gcc, also all the BSD flavours). And even when the fork ultimately isn't successful, it sometimes at least forces the original project to adapt (e.g. ffmpeg vs libav). E.g. "it's difficult to make predicitions, especially about the future" ;) PS: of course for this specific projec…

egcs was almost 30 years ago, fwiw.

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#79

Post by skeledrew »

andsoitis wrote: post #67
Skywalker13 wrote: post #37

I don't understand why the git history has been pruned in this fork. According to the first commit in this fork: > Squashed as a single orphan commit — the original oven-sh/bun history isn't relevant to this stripped fork and its shallow clone doesn't push cleanly to a fresh remote. IMHO it's always a bad decision to do that. Here, all commit authors are lost. The original history is always relevant.

> in this fork Not a fork, but a new project that takes a subset of the old Bun code to create something new, meant to complement Bun. “Cruller is not intended to replace Bun for development. It is a minimal, specialized runtime for executing production code. In any case, I do not want to throw away such a large codebase that has taken several years to build. It makes more sense to turn it into a convenient embeddabl…

A new project based primarily on existing code is still a fork. Also Ship of Theseus.

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#80

Post by fg137 »

sevenzero wrote: post #63
benrutter wrote: post #57

Earlier quoted context omitted.

Simple but pretty common use case: If you're ever looking at some pre-existing code and thinking "I don't really get why it's written like this?", you can get a lot out of looking through the git blame/history. Often "weird design" is there for historic reasons around stuff like backwards compatibility. If your project has a well managed commit log, you can find the notes of whoever implemented it, possibly even with…

That actually is helpful, but it would require a git history that actually makes sense. I rarely encounter well thought out git histories. For me its often just dev ramblings or 10 word commit messages

If I can choose "badly maintained history" and "no history" I'll choose the former every time. That's even less of a problem when Claude can do a first pass for you.
Post reply on HN