5 ms·

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 or

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.

actionfromafar 2mo 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 2mo ago
  I still would want the history easy to reach because when I find weird code I almost always reach directly to git log.
jeltz 2mo ago
Yeah, and of they want to only keep history for the subset thet are interested in there is always git filter-branch.
sevenzero 2mo 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 2mo ago
  Bug is uncovered. Where was it first introduced? Why was the code changed? What did it do before the bug was introduced?
  - sevenzero 2mo 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?
    - afavour 2mo 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 2mo ago
        Guess I must be doing something wrong to never have encountered this issue in my 5 years.
        loeg 2mo ago
        As you get better at engineering and grow into a senior, you'll find this more valuable.
        afavour 2mo ago
        You do you. But in my twenty years I’ve leaned on it countless times.
        klibertp 2mo ago
        I would ignore it if I spotted it once. This is the second 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. 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.
andsoitis 2mo 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.”
- skeledrew 2mo ago
  A new project based primarily on existing code is still a fork. Also Ship of Theseus.
  - otikik 2mo ago
    Wasn't the point of the Ship of Theseus precisely that establishing wether something is or isn't something else is at least complicated? Using it right after saying "X is still Y" kind of seems to make the opposite point.
    - skeledrew 2mo ago
      The point here is that even though the water is murky about it's intrinsic identity, we know that it's still a particular ship with a particular back story, making at least it's extrinsic identity an immutable known. Fairly similar to how - most, if not all - complex living organisms continually gain and lose composing cells throughout their lives, yet their individual identities remain fixed: "I am X and this is my dog Y". Similarly, a "fork" as we understand it in the context of software is this thing that, even though it's a modified copy, retains its extrinsic identity: "This software X was worked on in Y context, and is now being worked on in Z+ contexts". Same software, even if it gets a name change.
- Aurornis 2mo ago
  That's a fork. The git history should have been retained. It's helpful for the files that came over. There is no good reason to erase all of the history. They should have deleted the files they didn't want to keep in a new commit.
giancarlostoro 2mo ago
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!
- gandreani 2mo ago
  This doesn't apply here in this case since this is a continuation of the Zig based bun and the newer bun versions use Rust. There's no newer upstream changes to merge with the fork
  - giancarlostoro 2mo ago
    Yeah, I'm okay with this particular case to some degree, since its a completely different project, I guess I'm frustrated that I keep seeing projects adopting git squash because some guy somewhere has really terrible commit messages.
bjourne 2mo ago
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.

actionfromafar 2mo 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 2mo ago
I still would want the history easy to reach because when I find weird code I almost always reach directly to git log.

jeltz 2mo ago

Yeah, and of they want to only keep history for the subset thet are interested in there is always git filter-branch.

sevenzero 2mo 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 2mo ago
Bug is uncovered. Where was it first introduced? Why was the code changed? What did it do before the bug was introduced?
- sevenzero 2mo 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?
  - afavour 2mo 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 2mo ago
      Guess I must be doing something wrong to never have encountered this issue in my 5 years.
      - loeg 2mo ago
        As you get better at engineering and grow into a senior, you'll find this more valuable.
      - afavour 2mo ago
        You do you. But in my twenty years I’ve leaned on it countless times.
      - klibertp 2mo ago
        I would ignore it if I spotted it once. This is the second 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. 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.

andsoitis 2mo 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.”

skeledrew 2mo ago
A new project based primarily on existing code is still a fork. Also Ship of Theseus.
- otikik 2mo ago
  Wasn't the point of the Ship of Theseus precisely that establishing wether something is or isn't something else is at least complicated? Using it right after saying "X is still Y" kind of seems to make the opposite point.
  - skeledrew 2mo ago
    The point here is that even though the water is murky about it's intrinsic identity, we know that it's still a particular ship with a particular back story, making at least it's extrinsic identity an immutable known. Fairly similar to how - most, if not all - complex living organisms continually gain and lose composing cells throughout their lives, yet their individual identities remain fixed: "I am X and this is my dog Y". Similarly, a "fork" as we understand it in the context of software is this thing that, even though it's a modified copy, retains its extrinsic identity: "This software X was worked on in Y context, and is now being worked on in Z+ contexts". Same software, even if it gets a name change.
Aurornis 2mo ago
That's a fork. The git history should have been retained. It's helpful for the files that came over. There is no good reason to erase all of the history. They should have deleted the files they didn't want to keep in a new commit.

giancarlostoro 2mo ago

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!

gandreani 2mo ago
This doesn't apply here in this case since this is a continuation of the Zig based bun and the newer bun versions use Rust. There's no newer upstream changes to merge with the fork
- giancarlostoro 2mo ago
  Yeah, I'm okay with this particular case to some degree, since its a completely different project, I guess I'm frustrated that I keep seeing projects adopting git squash because some guy somewhere has really terrible commit messages.

bjourne 2mo ago

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.