61–70 of 127 posts
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?
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.
Earlier quoted context omitted.
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.
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…
Earlier quoted context omitted.
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.
Enables the best git command ever: git bisect
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?
Concrete example: yabridge is a tool to let Linux users run DAW plugins designed for Windows. Some changes to Wine (yabridge's main dependency) made yabridge stop working in 2024, and those Wine changes are not going to be undone as they advance progress on Wine's own bug list and test suite. When those changes were made, there wasn't a clear way to change the yabridge code to work with the modified Wine functions.
At the very least, if Wine and yabridge didn't keep a history of their code, you wouldn't even be able to download and build Wine 9.21 staging, when yabridge worked.
Every few weeks, a new dev will find this problem and look into fixing it. By having a history, this dev can always look back on the working implementation. Maybe one day there will be a series of function calls in the new Wine codebase that gets the same behavior that worked before? Maybe Wine adds a flag for yabridge that reintroduces the old functionality but retains for everyone else the changes they decided were necessary. Both avenues would fix the bug but from different ends.
(I understand Wine avoiding the flag solution: It's more to maintain just to help a single project, plus it introduces a conditional jump fail in the very active event handler and windowing subsystems affecting nearly every Wine user, and the development of Wine keeps moving, which could make a flag-based workaround redundant in the near future.)
I haven't opened my DAW in a few months. Last I knew, the problem is resolved for most users but not all, and there might have been a major breakthrough in April or May that still hasn't reached end users.
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.
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 embeddable library that can be used throughout the Zig ecosystem.”
One thing to point out is all the author's comments seem LLM generated and so does the README and the latest commit to the branch (large explanation in a comment and then change)..
AI / LLM usage disclosure
AI was used as an engineering assistant for parts of the Zig 0.16 migration, build/debug investigation, and focused test work. The project scope, architecture decisions, review of changes, and build/test verification remain maintainer-directed. This is not a purely AI-generated project.
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.
TL;DR: "never have encountered in 5 years" is a meaningless data point.
My professional career can legally drink beer since a few years back, yet I'm still regularly hitting "first times" on various things in my day job; I'm also frequently mind-blown reading about others' experiences in domains I never touched. Don't make those "5 years" into a badge to hide behind; use it as a springboard to reach higher.
In this case, try to actively think of uses for the commit history. It's already there; there's an expectation (admittedly, to various degrees depending on context) that it will be maintained. Try to maximize the value you get out of it. Underutilizing a tool you have access to may not be that much of a problem on average, but in some specific circumstances can make a difference between being able to complete a task at all or not. You shouldn't rely on luck to never land in a situation like that: familiarizing yourself with as many potential uses for a tool as possible gives you a better chance of handling it more easily.
EDIT: formatting, last paragraph.
Earlier quoted context omitted.
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?
"Bug uncovered" doesn't mean "bug fixed." Concrete example: yabridge is a tool to let Linux users run DAW plugins designed for Windows. Some changes to Wine (yabridge's main dependency) made yabridge stop working in 2024, and those Wine changes are not going to be undone as they advance progress on Wine's own bug list and test suite. When those changes were made, there wasn't a clear way to change the yabridge code t…
I don’t - Windows keeps a compatibility database for a reason. It seems inevitable that you’d need to maintain that too to keep apps working or drop support. The performance is a non-sequiter for a few reasons. Even in the hot path the conditional is going to get speculated away since the wine subsystem is uniquely instantiated per application. If you were really paranoid you could ship multiple binaries and select which ones to use dynamically at runtime. I suspect the bigger problem is one of maintenance - Microsoft does this with a huge budget and a huge team whose sole responsibility is maintaining that comparability. A community project is going to have to make more pragmatic choices.