Unclear relation with vanilla Forgejo (README describing as "fork") #2193

Chealer commented 2025年10月31日 20:54:00 +01:00

Comment

This flavor of Forgejo is described in the README as a "fork of Forgejo":

Codeberg's fork of Forgejo, a self-hosted lightweight software forge.

At least old-timers like myself will read that as meaning that work on the vanilla Forgejo will not benefit this project. But that does not seem to be the case, "fork" being used in its lesser/jargonic sense of a copy, which usually results in a "soft fork" (aka "active fork", "development fork", "tracking fork"). The README only clarifies the meaning in its Contributing section:

We follow the upstream Forgejo tree and most of the decisions that they make for everyone else.

Even that is quite unclear, since "following a tree" could just mean manually checking what changed there, possibly replicating once in a while.

In any case, it would be much less confusing to clearly specify:

1. whether changes in vanilla Forgejo are merged in "Forgejo (Codeberg)"
2. when "Forgejo (Codeberg)" was [last] forked
3. if there are regular merges, how they are performed.

License

This report (including all messages and attachments I add to it) is offered under the terms of CC0 1.0.

### Comment This flavor of Forgejo is described in [the README](https://codeberg.org/Codeberg-Infrastructure/forgejo/src/branch/codeberg-13/README.md) as a "fork of Forgejo": > Codeberg's fork of Forgejo, a self-hosted lightweight software forge. At least old-timers like myself will read that as meaning that work on the vanilla Forgejo will not benefit this project. But that does not seem to be the case, "fork" being used in its lesser/jargonic sense of a copy, which usually results in a "soft fork" (aka "active fork", "development fork", "tracking fork"). The README only clarifies the meaning in its _Contributing_ section: > We follow the upstream Forgejo tree and most of the decisions that they make for everyone else. Even that is quite unclear, since "following a tree" could just mean manually checking what changed there, possibly replicating once in a while. In any case, it would be much less confusing to clearly specify: 1. whether changes in vanilla Forgejo are merged in "Forgejo (Codeberg)" 2. when "Forgejo (Codeberg)" was [last] forked 3. if there are regular merges, how they are performed. <details> <summary>License</summary> This report (including all messages and attachments I add to it) is offered under the terms of CC0 1.0. </details>

Gusted commented 2025年10月31日 21:33:42 +01:00

I'm not entirely convinced this solves a problem. You're free to propose a README that clarifies what you think is unclear currently, but otherwise the current README is not ambiguous.

In any case, it would be much less confusing to clearly specify:

All of this information can be derived by looking at the commit history.

I'm not entirely convinced this solves a problem. You're free to propose a README that clarifies what you think is unclear currently, but otherwise the current README is not ambiguous. > In any case, it would be much less confusing to clearly specify: All of this information can be derived by looking at the commit history.