alt Hacker NewsI 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.
Replies
Yeah, and of they want to only keep history for the subset thet are interested in there is always git filter-branch.
Yeah, this is one thing you should absolutely never, ever do as a responsible developer. It makes future debugging much more difficult (destroys git blame) and also is a huge dump on previous contributors who don't get credit for their work in the fork. If solenopsys is serious about the fork he should redo it. Throwing away history willy-nilly is such a giant red flag that I think he will have trouble attracting any contributors.
I hate that people git squash merges into dev, it always adds an extra layer of unnecessary ceremony when fixing your original branch, as opposed to just pulling the latest back into your original branch, then fixing the one line or whatever that was affected after merge, and now your git history is incompatible, so you have to delete your local branches because they're pointless now. Git squash should be done before your PR if you want to nuke dumb commits, but I prefer to have it all, if you want to find the key commits, tag them!
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.
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.
> 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.”