Skywalker13
3 hours ago
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.
andsoitis
34 minutes ago
> 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 embeddable library that can be used throughout the Zig ecosystem.”
jeltz
2 hours ago
Yeah, and of they want to only keep history for the subset thet are interested in there is always git filter-branch.
actionfromafar
2 hours ago
If I'm taking a project in a completely different direction, with different people, I might not care about commit history very much. But I worry more from a licensing standpoint. Unless a project has a strict copyright re-assignment policy (uncommon) where all contributors sign over their copyright (not just contribute their "patch" under the designated license), the copyrYight history is lost or at best muddled.
Now, in practical terms, one can always go back to the original repo and find it. But if I was doing this in a corporate $DAYJOB, I'd keep the history just to be sure.
jeltz
2 hours ago
I still would want the history easy to reach because when I find weird code I almost always reach directly to git log.
sevenzero
an hour ago
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.
cpuguy83
an hour ago
Bug is uncovered. Where was it first introduced? Why was the code changed? What did it do before the bug was introduced?
sevenzero
an hour ago
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?
PennRobotics
39 minutes ago
"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 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.
vlovich123
a few seconds ago
> I understand Wine avoiding the flag solution
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.
afavour
an hour ago
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.
sevenzero
an hour ago
Guess I must be doing something wrong to never have encountered this issue in my 5 years.
klibertp
3 minutes ago
I would ignore it if I spotted it once. This is the third time, though, so I probably should point it out: 5 years is a very short time in terms of personal experience and development. While the whole industry moves very fast, it does so thanks to slow, grinding effort parallelized over hundreds of thousands of individuals. For an organization, 5 years is an era. For individuals, it's just 3-6 projects (+/- a few, depending on the context you work in).
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.
afavour
an hour ago
You do you. But in my twenty years I’ve leaned on it countless times.
StilesCrisis
an hour ago
You can see what the code looked like before the bug was added, and in many cases, just change it back to how it used to be?
The most obvious use case for history is "roll back this entire CL, it's broken".
Shatnerz
an hour ago
Checking git history is one of the first things I do when I find unfamiliar code or when I'm debugging something. Git history contains a lot of context that helps speed up the rest of the process
owaislone
an hour ago
Enables the best git command ever: git bisect
imron
41 minutes ago
Yes! An incredible tool. You'll rarely need to use it, but when you do it's invaluable.
benrutter
an hour ago
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 their motivation for doing so.
At the very least, you can find out who wrote that code and ask them about it.
There's a tonne of data in git histories - this article was shared a few months back and is an awesome example of some things you can do with git history: https://piechowski.io/post/git-commands-before-reading-code/
sevenzero
an hour ago
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