#131 - From Forking to Forging: Designing a modern contribution workflow for the future - forgejo/discussions - Codeberg.org

#131 - From Forking to Forging: Designing a modern contribution workflow for the future - forgejo/discussions - Codeberg.org
forgejo
discussions
Issues
190
Activity
From Forking to Forging: Designing a modern contribution workflow for the future
#131
New issue
Open
opened
2024-03-10 01:03:35 +01:00
by
fnetX
42 comments
fnetX
commented
2024-03-10 01:03:35 +01:00
Owner
Copy link
Recently, people started to question the workflow Forgejo inherited from GitHub which uses "Forks" in order to contribute to a project. The top alternative is the "AGit" worklfow which has seen recent improvements.
History recap
in 2021,
Gitea gained AGIt support
which allows to send patches without a fork
after not much initial attention, core Codeberg contributors started to wonder about it in November 2023, motivated by the duplication problem forks create
the AGit setup was promoted and used by some Codeberg members and gained attention
there have been some convenience improvements to the AGit usability
The usability of forking
The concept of forking was promoted by GitHub, together with the concept of "Pull Requests". The latter existed before, but the term technically feels a little wrong (you ask someone to pull your changes from a remote, which is not really remote but placed on the same server. And if accepted, the other party goes to your changes to get them in. This kinda creates a knot in my head. Why not say "Proposed Changes" which doesn't involve multiple virtual roundtrips).
However, consider what users want to do:
there is a problem in a file
I want to edit it (e.g. in the GUI or locally)
I want to propose my change
I want to be done about it.
These simple steps are extended with unnecessary steps like
Before I can edit a file, I have to create a fork
when proposing my change, I need to take care of the branches
Or, when working locally with the Git cli:
I need to add multiple remotes
I need to ensure to pull changes from one remote, and push to a different remote
There is no technical necessity for this complication. Forgejo already allows to propose changes without a fork, and to edit in the GUI. It's just not connected. Currently, modifying a file without a fork asks you to create a fork first.
Further problems with forks
There are numerous issues with forks. I propose not to invest any human resources into solving them, and instead close the following issues:
forks get out of sync and need updating
and you want to know when this is the case
forgejo/forgejo#677
and you want a button to fix it
forgejo/forgejo#471
updating a file without having a fork is not possible
forgejo/forgejo#559
forks sometimes break for some reason
forgejo/forgejo#2589
(the chances of having inconsistencies when using separate independent folders appears to be much higher than with using a single source of truth, at least to me)
migrating forks is partially broken due to the issue above
forgejo/forgejo#2532
(storing pull request references without referencing an actual fork when migrating would solve the issue)
there are confusions about when a fork can be made to different contexts, and bugs that originate from there
forgejo/forgejo#2504
the bug about branch edits in pull requests from private forks might be not be present
forgejo/forgejo#1461
forks clutter your personal repos over time, because you must manually remove them
forks accumulate duplicated storage over time, because even with initial de-duplication, the updates are pushed independently and there is no de-duplication happening; this might also be the case with Garbage collection
forgejo/forgejo#4957
it's complicated (or impossible?) to create pull requests to forks, you'd probably need to fork the fork, which is also not possible? Heck, it's complex.
duplicate issues like
forgejo/forgejo#8045
Conduct User Research
While many people in the Forgejo space already have an idea of how a solution to this could look like, I propose (and commit myself) to perform some attempt at user research specifically for this topic. The benefit is that we gain a better idea of what to think of and which usecases to support. And if our first attempt at user research does not work out, we still have all our ideas as a fallback, so I think it's the best possible start.
User Research should answer questions for us like:
Familiarity of users with code tools, Git CLI etc (do they know how to …? Do they already know how to fork, or are they new to the software?)
check if and how users use the web UI editors vs the Git CLI
learn about edge cases in workflows, e.g. pull requests to forks, preparing work in forks together etc (so they remain possible with a new workflow)
learn about review requirements of users to decide whether AGit is "good enough" or if we should come up with something that is closer to "pushing a branch to a fork"
check if users want to revisit their changes later (e.g. access lists of their branches in a fork)
check on the need to upload changes to a server without creating a PR (currently possible in forks)
get the idea of what people count as contributors (currently, the number of forks acts as an estimate of contributors, and we need to find an equivalent to it)
Designing the Forge-process of the future
This roadmap is of course to be updated with the results of the user research. I am still sharing a draft, because I feel like some people who are familiar with the fork-based workflow find it hard to imagine how things would look without
the fork-based workflow is kept available as a fallback for the time being, but no additional human resources are invested into it
the fork button is replaced by a "Contribute" button
a number next to it displays a contributor metric, e.g. the number of people with accepted pull request - or even a number including non-code contributions somehow
there is either a drop-down that offers multiple choices including the previous fork style,
OR
there is a contributing page which explains how to push changes to the remote:
clone the repo
select a branch and do changes
push with a special command line
the contributing page could also include contribution guidelines and further options described by the project, e.g. render a "CONTRIBUTING.md" file, mainly to cover project-specific details and encourage non-code contributions which do not rely on that specific workflow
forgejo/forgejo#2381
it is possible to interactively manage PRs
it is possible to easily edit a file in the Web UI without creating a fork (just edit a file, propose the change, have a quick way to fix typos)
it is possible to create PRs to other people's PRs to enhance something together (workaround: ask the maintainers to create a new branch and collaborate there)
consider renaming pull requests, e.g. to "Proposed Changes" or "Patches" … ?!
Wrapping it up
This is a large undertaking, but inevitable if you ask me. The fork-based workflow does not make much sense, it never did. We just got used to making some extra steps instead of going a straight line.
There is already some base work that allows to collaborate without forks. I believe that it is easier to build a proper contribution workflow without forks, compared to solving the issues with the forks itself (duplication, PRs to forks etc etc).
Improving the usability for working together is a key feature of Forgejo. Making it easier to contribute to projects can lower the entry barrier for projects a lot.
I am looking forward to finally getting rid of the fork-legacy we inherited and design a modern and easy contribution workflow that enables both quick interaction for people without deep knowledge of Git possible, as well as productivity for people who use GIt every day.
Are you in?
Recently, people started to question the workflow Forgejo inherited from GitHub which uses "Forks" in order to contribute to a project. The top alternative is the "AGit" worklfow which has seen recent improvements.

## History recap

- in 2021, [Gitea gained AGIt support](https://github.com/go-gitea/gitea/pull/14295) which allows to send patches without a fork
- after not much initial attention, core Codeberg contributors started to wonder about it in November 2023, motivated by the duplication problem forks create
- the AGit setup was promoted and used by some Codeberg members and gained attention
- there have been some convenience improvements to the AGit usability

## The usability of forking

The concept of forking was promoted by GitHub, together with the concept of "Pull Requests". The latter existed before, but the term technically feels a little wrong (you ask someone to pull your changes from a remote, which is not really remote but placed on the same server. And if accepted, the other party goes to your changes to get them in. This kinda creates a knot in my head. Why not say "Proposed Changes" which doesn't involve multiple virtual roundtrips).

However, consider what users want to do:

- there is a problem in a file
- I want to edit it (e.g. in the GUI or locally)
- I want to propose my change
- I want to be done about it.

These simple steps are extended with unnecessary steps like

- Before I can edit a file, I have to create a fork
- when proposing my change, I need to take care of the branches

Or, when working locally with the Git cli:

- I need to add multiple remotes
- I need to ensure to pull changes from one remote, and push to a different remote

There is no technical necessity for this complication. Forgejo already allows to propose changes without a fork, and to edit in the GUI. It's just not connected. Currently, modifying a file without a fork asks you to create a fork first.

## Further problems with forks

There are numerous issues with forks. I propose not to invest any human resources into solving them, and instead close the following issues:

- forks get out of sync and need updating
- and you want to know when this is the case https://codeberg.org/forgejo/forgejo/issues/677
- and you want a button to fix it https://codeberg.org/forgejo/forgejo/issues/471
- updating a file without having a fork is not possible https://codeberg.org/forgejo/forgejo/issues/559
- forks sometimes break for some reason https://codeberg.org/forgejo/forgejo/issues/2589 (the chances of having inconsistencies when using separate independent folders appears to be much higher than with using a single source of truth, at least to me)
- migrating forks is partially broken due to the issue above https://codeberg.org/forgejo/forgejo/issues/2532 (storing pull request references without referencing an actual fork when migrating would solve the issue)
- there are confusions about when a fork can be made to different contexts, and bugs that originate from there https://codeberg.org/forgejo/forgejo/issues/2504
- the bug about branch edits in pull requests from private forks might be not be present https://codeberg.org/forgejo/forgejo/issues/1461
- forks clutter your personal repos over time, because you must manually remove them
- forks accumulate duplicated storage over time, because even with initial de-duplication, the updates are pushed independently and there is no de-duplication happening; this might also be the case with Garbage collection https://codeberg.org/forgejo/forgejo/issues/4957
- it's complicated (or impossible?) to create pull requests to forks, you'd probably need to fork the fork, which is also not possible? Heck, it's complex.
- duplicate issues like https://codeberg.org/forgejo/forgejo/issues/8045

## Conduct User Research

While many people in the Forgejo space already have an idea of how a solution to this could look like, I propose (and commit myself) to perform some attempt at user research specifically for this topic. The benefit is that we gain a better idea of what to think of and which usecases to support. And if our first attempt at user research does not work out, we still have all our ideas as a fallback, so I think it's the best possible start.

User Research should answer questions for us like:

- Familiarity of users with code tools, Git CLI etc (do they know how to …? Do they already know how to fork, or are they new to the software?)
- check if and how users use the web UI editors vs the Git CLI
- learn about edge cases in workflows, e.g. pull requests to forks, preparing work in forks together etc (so they remain possible with a new workflow)
- learn about review requirements of users to decide whether AGit is "good enough" or if we should come up with something that is closer to "pushing a branch to a fork"
- check if users want to revisit their changes later (e.g. access lists of their branches in a fork)
- check on the need to upload changes to a server without creating a PR (currently possible in forks)
- get the idea of what people count as contributors (currently, the number of forks acts as an estimate of contributors, and we need to find an equivalent to it)

## Designing the Forge-process of the future

This roadmap is of course to be updated with the results of the user research. I am still sharing a draft, because I feel like some people who are familiar with the fork-based workflow find it hard to imagine how things would look without

- the fork-based workflow is kept available as a fallback for the time being, but no additional human resources are invested into it
- the fork button is replaced by a "Contribute" button
- a number next to it displays a contributor metric, e.g. the number of people with accepted pull request - or even a number including non-code contributions somehow
- there is either a drop-down that offers multiple choices including the previous fork style, **OR**
- there is a contributing page which explains how to push changes to the remote:
- clone the repo
- select a branch and do changes
- push with a special command line
- the contributing page could also include contribution guidelines and further options described by the project, e.g. render a "CONTRIBUTING.md" file, mainly to cover project-specific details and encourage non-code contributions which do not rely on that specific workflow
- https://codeberg.org/forgejo/forgejo/issues/2381 it is possible to interactively manage PRs
- it is possible to easily edit a file in the Web UI without creating a fork (just edit a file, propose the change, have a quick way to fix typos)
- it is possible to create PRs to other people's PRs to enhance something together (workaround: ask the maintainers to create a new branch and collaborate there)
- consider renaming pull requests, e.g. to "Proposed Changes" or "Patches" … ?!

## Wrapping it up

This is a large undertaking, but inevitable if you ask me. The fork-based workflow does not make much sense, it never did. We just got used to making some extra steps instead of going a straight line.

There is already some base work that allows to collaborate without forks. I believe that it is easier to build a proper contribution workflow without forks, compared to solving the issues with the forks itself (duplication, PRs to forks etc etc).

Improving the usability for working together is a key feature of Forgejo. Making it easier to contribute to projects can lower the entry barrier for projects a lot.

I am looking forward to finally getting rid of the fork-legacy we inherited and design a modern and easy contribution workflow that enables both quick interaction for people without deep knowledge of Git possible, as well as productivity for people who use GIt every day.

Are you in?
14
❤️
19
fnetX
commented
2024-03-10 01:17:28 +01:00
Author
Owner
Copy link
We should also try to take requirements for federation into consideration. I am not involved with the matter at the moment, but I would imagine that building a federated network that just sends changes to a branch and creates a discussion about it is much easier to implement than deciding on forks.
Forks would only start to make sense to have a copy of an upstream project on a remote instance (of the contributor, if separate from the project itself).
We should also try to take requirements for federation into consideration. I am not involved with the matter at the moment, but I would imagine that building a federated network that just sends changes to a branch and creates a discussion about it is much easier to implement than deciding on forks.

Forks would only start to make sense to have a copy of an upstream project on a remote instance (of the contributor, if separate from the project itself).
oliverpool
commented
2024-03-10 07:01:31 +01:00
Member
Copy link
I think this is a great idea!
I successfully used the AGit workflow to automate PR creation via a woodpecker cron (which is run with a permissionless user).
As a first step, maybe we should gather the “usual step” for the fork-model and document the equivalent for AGit. (For instance I am not sure how if I can use the “—set-upstream” flag with AGit so that after initial PR creation, I can send other changes.)
I see the following scenarios:
proposing a simple fix (already well documented)
adjusting the fix according to feedback (the commands are a bit more convoluted than just “git push (—force)”; could this be simplified?)
if someone else want to checkout the PR, how should they proceed ? (this as seen recent improvements)
I think this is a great idea!

I successfully used the AGit workflow to automate PR creation via a woodpecker cron (which is run with a permissionless user).

As a first step, maybe we should gather the “usual step” for the fork-model and document the equivalent for AGit. (For instance I am not sure how if I can use the “—set-upstream” flag with AGit so that after initial PR creation, I can send other changes.)

I see the following scenarios:
- proposing a simple fix (already well documented)
- adjusting the fix according to feedback (the commands are a bit more convoluted than just “git push (—force)”; could this be simplified?)
- if someone else want to checkout the PR, how should they proceed ? (this as seen recent improvements)
viceice
commented
2024-03-10 07:40:03 +01:00
Owner
Copy link
I think this is good for small changes, but too complicated for big ongoing PR's.
we shouldn't drop forks completely, may allow to disable.
I think this is good for small changes, but too complicated for big ongoing PR's.

we shouldn't drop forks completely, may allow to disable.
algernon
commented
2024-03-10 09:53:19 +01:00
Member
Copy link
While I agree that encouraging a fork-less contributor workflow (such as AGit) has its benefit, and I'm all for it, we need to make sure it is
less
painful than the fork + pull request model.
For example, with pull requests, it's easy to visit the sending branch on the web ui: just click on it. With the AGit workflow, we can't currently do that. The only way to look at the
entire tree
on the web is to look at the top commit. That's not a predictable URL one can share.
And as
@oliverpool
said above: we need a way for contributors to check the PR out locally too. While
git fetch origin pull/{id}/head:{local-branch-name}
does work for both AGit and fork-based PRs, checking out the branch by name rather than pull id would be much more convenient.
I also agree with
@viceice
, that both workflows should be able to co-exist.
While I agree that encouraging a fork-less contributor workflow (such as AGit) has its benefit, and I'm all for it, we need to make sure it is *less* painful than the fork + pull request model.

For example, with pull requests, it's easy to visit the sending branch on the web ui: just click on it. With the AGit workflow, we can't currently do that. The only way to look at the *entire tree* on the web is to look at the top commit. That's not a predictable URL one can share.

And as @oliverpool said above: we need a way for contributors to check the PR out locally too. While `git fetch origin pull/{id}/head:{local-branch-name}` does work for both AGit and fork-based PRs, checking out the branch by name rather than pull id would be much more convenient.

I also agree with @viceice, that both workflows should be able to co-exist.
fnetX
commented
2024-03-10 12:33:49 +01:00
Author
Owner
Copy link
I do not want to force everyone into AGit. If that was the case, there would be no need to "design" a new workflow. AGit serves as a good example that something better than forking already exists in the codebase. However, my goal is to design something really easy to use that does not involve the extra step "forking".
The need for a fork does not make any sense in my opinion, it's just a bad habit we should get rid off. My personal preference for a workflow would look like this:
you clone a repo
you create a branch
you push the branch back to the repo which enforces a certain namespace like
from_username/original_branchname
, or a similar prefix which is unlikely to conflict
these special branches are not included in normal clones from the repo but can only be fetched with a special command, like
git fetch origin u_username/branch/head:{local_branch}
the special branches can be listed in the web UI, but they are marked differently than the original branches
it is possible to visit a branch from a pull request (e.g. by clicking on the url which is currently disabled for AGit)
user branches show a warning when browsed ("This branch shows contributions from User. The content is not endorsed by the official project") or something like this.
pushing to such a branch also prompts you to create a pull request
pull requests should show instructions for fetching the content; this has also been a problem with the fork-based workflow, I still don't know how it works tbh
it is possible to remove user branches (e.g. with inappropriate content or if they use a lot of space)
I do not want to force everyone into AGit. If that was the case, there would be no need to "design" a new workflow. AGit serves as a good example that something better than forking already exists in the codebase. However, my goal is to design something really easy to use that does not involve the extra step "forking".

The need for a fork does not make any sense in my opinion, it's just a bad habit we should get rid off. My personal preference for a workflow would look like this:

- you clone a repo
- you create a branch
- you push the branch back to the repo which enforces a certain namespace like `from_username/original_branchname`, or a similar prefix which is unlikely to conflict
- these special branches are not included in normal clones from the repo but can only be fetched with a special command, like `git fetch origin u_username/branch/head:{local_branch}`
- the special branches can be listed in the web UI, but they are marked differently than the original branches
- it is possible to visit a branch from a pull request (e.g. by clicking on the url which is currently disabled for AGit)
- user branches show a warning when browsed ("This branch shows contributions from User. The content is not endorsed by the official project") or something like this.
- pushing to such a branch also prompts you to create a pull request
- pull requests should show instructions for fetching the content; this has also been a problem with the fork-based workflow, I still don't know how it works tbh
- it is possible to remove user branches (e.g. with inappropriate content or if they use a lot of space)
n0toose
referenced this issue from forgejo/forgejo
2024-03-10 13:05:16 +01:00
Agit: Provide instructions for fetching AGit-created Pull Requests
#2474
n0toose
commented
2024-03-10 13:10:14 +01:00
Member
Copy link
Here's an example of how Gerrit does it:
(URL)
I would love to have something close to this that does not compromise on the details (such as the
.patch
file) and also does so in a more "Forgejo"-y way without coming across as "weird" to users coming from GitHub. There's definitely a balance to strike here.
Here's an example of how Gerrit does it:

 [(URL)](https://review.haiku-os.org/c/haiku/+/6087)


I would love to have something close to this that does not compromise on the details (such as the `.patch` file) and also does so in a more "Forgejo"-y way without coming across as "weird" to users coming from GitHub. There's definitely a balance to strike here.
image.png
225 KiB
image.png
225 KiB
n0toose
referenced this issue from forgejo/forgejo
2024-03-10 13:10:50 +01:00
Agit: Provide instructions for fetching AGit-created Pull Requests
#2474
fnetX
referenced this issue from Codeberg/Contributing
2024-03-10 23:31:24 +01:00
[Team] Backups
#45
Kladky
commented
2024-03-12 19:41:14 +01:00
Copy link
I think there may be value in also encouraging cli clients such as
fjo
to put such workflows front and centre, since push options aren't really such a nice way to do since you have to keep putting
-o
(for example, who uses
-m
multiple times for commit messages?) and also specify the ref. Ideally forgejo could just pickup when you try to push to a repo which you don't have access to and figure out you want to make a contribution. From there an interactive PR could be make (
forgejo/forgejo#2381
), or details can be filled in automatically (gitlab does this when you use
-o merge_request.create
, derived from the first commit name & description).
I think there may be value in also encouraging cli clients such as [fjo](https://codeberg.org/VoiDD/fjo) to put such workflows front and centre, since push options aren't really such a nice way to do since you have to keep putting `-o` (for example, who uses `-m` multiple times for commit messages?) and also specify the ref. Ideally forgejo could just pickup when you try to push to a repo which you don't have access to and figure out you want to make a contribution. From there an interactive PR could be make (https://codeberg.org/forgejo/forgejo/issues/2381), or details can be filled in automatically (gitlab does this when you use `-o merge_request.create`, derived from the first commit name & description).
Kladky
referenced this issue from VoiDD/fjo
2024-03-12 19:44:14 +01:00
Completion tracker
#14
noth
commented
2024-03-14 21:49:50 +01:00
Copy link
Working on adding support for agit in fjo. At that point it could just be used instead of git (it will wrap git but that's implementation details) for any workflows.
Working on adding support for agit in fjo. At that point it could just be used instead of git (it will wrap git but that's implementation details) for any workflows.
n0toose
commented
2024-03-14 22:19:04 +01:00
Member
Copy link
@noth
@noth https://forgejo.org/docs/latest/user/agit-support/ ?
oliverpool
commented
2024-03-14 22:27:19 +01:00
Member
Copy link
@n0toose
VoiDD/fjo#14
(fjo is a cli tool for Forgejo, I gather ;)
@n0toose https://codeberg.org/VoiDD/fjo/issues/14 (fjo is a cli tool for Forgejo, I gather ;)
n0toose
commented
2024-03-14 22:48:32 +01:00
Member
Copy link
Oops, didn't read the whole thread, sorry =)
Oops, didn't read the whole thread, sorry =)
fnetX
referenced this issue from forgejo/forgejo
2024-03-15 13:23:09 +01:00
[FIX] Display error message if doer is unable to fork
#2649
fnetX
referenced this issue from forgejo/user-research
2024-03-23 02:13:43 +01:00
Redesign: Contribution workflow
#22
fnetX
referenced this issue
2024-04-19 19:11:28 +02:00
Your Motivation and goals for 2024
#158
fnetX
referenced this issue
2024-04-29 22:37:14 +02:00
We need a UI team
#160
fnetX
referenced this issue from forgejo/forgejo
2024-05-02 16:30:37 +02:00
[FEAT] Include hint to generate a user profile summary in user profile
#3605
smxi
commented
2024-05-25 20:05:08 +02:00
Copy link
get the idea of what people count as contributors (currently, the number of forks acts as an estimate of contributors, and we need to find an equivalent to it)
pointed me to this re the question of forks. I like the way you are approaching this issue, but would add that someone who forks a project almost always is cloning the code, usually because they are curious. In my experience:
you see 88 'forks', but maybe 2 of those were actual contributors, and you correctly note, having these dead end forks lying around is just clutter. It's also terminologically very confusing because the actual term fork means you forked the project, and are going to now move it into a different direction.
Speaking for myself, I totally ignore forks as an indication of anything at all, since they have no meaning, and certainly do not have anything to do with active contributors in my experience. I view contributors as anyone who has supplied data or possible patch or clear suggestions about where to find the information, with no real mapping at all to forking behaviors. In other words, a contributor may or may not have cloned the repo, but cloning the repo has no necessary relation to someone being a contributor, and thus are a very poor way to indicate active contributions. That would come from issues, and PR mainly.
For example, I forked infobash and created, with the original authors blessing, inxi. Or flac2ogg.pl into acxi. Those are forks, they replace the old dormant project and move it forwards. The github use of the term
fork
has always bugged me because it's silly and inaccurate, and confusing when searching for repos if you don't know the author, you always have to confirm what is the true project. It's also confusing for search engines, who have no real way to differentiate the source and
forks
Calling it a clone makes it crystal clear that it is a clone, not the master branch, and also makes it clear that being a clone, it's not going to be current most likely, unlike a fork, which implies that the fork is the active branch being developed, which is why it was forked.
In a sense, the challenge is to undo a really bad decision github made, and which users grew to consider as 'how it's done'. And not to carry those forwards, thus amplifying the problem created by bad semantics.
I don't understand all the points raised here, but this is my view as a source repo user, who has always intensely disliked how github did this, and how its users grew to not understand what the concepts are.
Obviously the simplest is the oldest: here is a diff, I cloned your repo, and created this suggested patch.
Speaking for myself, I've never minded the concept of pull request (though I find it confusing, because actually the person is pushing to your master branch, and is requesting you pull their push), because really all it is is a diff or patch. But I'm not a good person to ask because I've never liked git or its branching method, and just speaking for myself, wouldn't accept anything like a branched version since to me that's just confusing and highly prone to failure, hard to recover from if it goes wrong. Note that's not a factual statement based on being expert git user, it's just my experience as a person who learned just what is required and no more. But I like the method of getting a patch, aka pull request/PR, and accepting it, that to me is completely fine. It's easy and reasonably intuitive.
I don't know if it's a feature, but it seems to me that the ideal way to handle clones is to have an 'update from master' button so you can bring the clone into sync with master again, without creating endless clutters.
I assume there would then be a way to not store it as a duplicate copy, but just as basically a diff from the master copy, but I don't know how git works internally. This is probably what that agit thing is related to I'd guess though I'd never heard of it until this thread.
I don't know if this is useful, but it's just my feedback on what I think was always my total pet peeve with github, the totally wrong fork concept.
A real fork should be active, be getting ongoing code contributions and updates, and should be a reserved term only used for those extremely rare cases of an actual fork, which for most projects almost never happen.
> get the idea of what people count as contributors (currently, the number of forks acts as an estimate of contributors, and we need to find an equivalent to it)

Speaking for myself, I totally ignore forks as an indication of anything at all, since they have no meaning, and certainly do not have anything to do with active contributors in my experience. I view contributors as anyone who has supplied data or possible patch or clear suggestions about where to find the information, with no real mapping at all to forking behaviors. In other words, a contributor may or may not have cloned the repo, but cloning the repo has no necessary relation to someone being a contributor, and thus are a very poor way to indicate active contributions. That would come from issues, and PR mainly.

For example, I forked infobash and created, with the original authors blessing, inxi. Or flac2ogg.pl into acxi. Those are forks, they replace the old dormant project and move it forwards. The github use of the term _fork_ has always bugged me because it's silly and inaccurate, and confusing when searching for repos if you don't know the author, you always have to confirm what is the true project. It's also confusing for search engines, who have no real way to differentiate the source and _forks_.

Calling it a clone makes it crystal clear that it is a clone, not the master branch, and also makes it clear that being a clone, it's not going to be current most likely, unlike a fork, which implies that the fork is the active branch being developed, which is why it was forked.

In a sense, the challenge is to undo a really bad decision github made, and which users grew to consider as 'how it's done'. And not to carry those forwards, thus amplifying the problem created by bad semantics.

I don't understand all the points raised here, but this is my view as a source repo user, who has always intensely disliked how github did this, and how its users grew to not understand what the concepts are.

Obviously the simplest is the oldest: here is a diff, I cloned your repo, and created this suggested patch.

Speaking for myself, I've never minded the concept of pull request (though I find it confusing, because actually the person is pushing to your master branch, and is requesting you pull their push), because really all it is is a diff or patch. But I'm not a good person to ask because I've never liked git or its branching method, and just speaking for myself, wouldn't accept anything like a branched version since to me that's just confusing and highly prone to failure, hard to recover from if it goes wrong. Note that's not a factual statement based on being expert git user, it's just my experience as a person who learned just what is required and no more. But I like the method of getting a patch, aka pull request/PR, and accepting it, that to me is completely fine. It's easy and reasonably intuitive.

I don't know if it's a feature, but it seems to me that the ideal way to handle clones is to have an 'update from master' button so you can bring the clone into sync with master again, without creating endless clutters.

I assume there would then be a way to not store it as a duplicate copy, but just as basically a diff from the master copy, but I don't know how git works internally. This is probably what that agit thing is related to I'd guess though I'd never heard of it until this thread.

I don't know if this is useful, but it's just my feedback on what I think was always my total pet peeve with github, the totally wrong fork concept.

A real fork should be active, be getting ongoing code contributions and updates, and should be a reserved term only used for those extremely rare cases of an actual fork, which for most projects almost never happen.
fnetX
referenced this issue from forgejo/forgejo
2024-06-24 21:26:19 +02:00
Soft-quota foundations
#4212
fnetX
referenced this issue from forgejo/forgejo
2024-07-01 13:54:43 +02:00
fix(hook): ignore unknown push options instead of failing
#4253
fnetX
referenced this issue
2024-07-07 21:41:58 +02:00
A new workflow for design work and feature requests
#178
fnetX
referenced this issue from forgejo/design
2024-07-23 02:43:19 +02:00
Contribution workflow
#7
fnetX
referenced this issue from forgejo/forgejo
2024-08-11 18:04:22 +02:00
feat: allow aGit PR to be a PR target
#4929
matrss
referenced this issue from forgejo-aneksajo/forgejo-aneksajo
2024-08-15 11:23:36 +02:00
[FEAT] Support AGit-Flow with git-annex
#32
fnetX
referenced this issue from forgejo/forgejo
2024-08-18 23:27:36 +02:00
feat: git object deduplication by using git alternates
#4957
wolftune
commented
2024-12-07 02:26:59 +01:00
Copy link
A related issue I had opened up in Gitea is relevant to consider:
I won't copy everything here unless that's requested.
Overall, I strongly share the goal of making the Forgejo UI provide a better straightforward way for contributors to suggest changes.
A related issue I had opened up in Gitea is relevant to consider:

I won't copy everything here unless that's requested.

Overall, I strongly share the goal of making the Forgejo UI provide a better straightforward way for contributors to suggest changes.
fnetX
referenced this issue from forgejo/forgejo
2024-12-16 12:45:32 +01:00
bug: Edit button on files wrongly claims it requires the presence of a fork
#6273
fnetX
referenced this issue from forgejo/sustainability
2025-01-16 00:33:51 +01:00
Workplan for the April 2025 NLnet application
#74
fnetX
referenced this issue from forgejo/forgejo
2025-01-27 23:03:59 +01:00
ITS: Term "issue" conflated with tickets (issue reports), in documentation (The Basics of Issue Tracking) and elsewhere
#6697
Chealer
commented
2025-01-29 15:48:19 +01:00
Copy link
Hi
@fnetX
I do not know AGit and do not master Git enough to comment on the core proposal, but I share concerns about "Forking", at least with regards to terminology.
@fnetX
wrote in
#131 (comment)
[…]
The concept of forking was promoted by GitHub, together with the concept of "Pull Requests". The latter existed before, but the term technically feels a little wrong (you ask someone to pull your changes from a remote, which is not really remote but placed on the same server. And if accepted, the other party goes to your changes to get them in. This kinda creates a knot in my head. Why not say "Proposed Changes" which doesn't involve multiple virtual roundtrips).
Amen
[…]
* consider renaming pull requests, e.g. to "Proposed Changes" or "Patches" … ?!
"Patches" certainly comes to mind, but seems like a suboptimal choice given its association with patch files, which are of course very related but also different, and because the non-technological sense of patch is something which fixes something broken, which is not the only purpose of proposed changes.
I very much prefer "Proposed changes", but then that's significantly longer and poorly abbreviable. Also, is a merge request
a proposed change
or
proposed change
? Also, "proposed changes" sounds like they are pending acceptance; if we want to say discuss statistics about those which have already been accepted, or discuss those which haven't been proposed yet, and avoid the pluralization issue, "Change proposal(s)" would be better. But "Source change proposal" (SCP) would be more precise and abbreviable.
Hi @fnetX,

I do not know AGit and do not master Git enough to comment on the core proposal, but I share concerns about "Forking", at least with regards to terminology.

@fnetX wrote in https://codeberg.org/forgejo/discussions/issues/131#issue-718263:

> […]
> The concept of forking was promoted by GitHub, together with the concept of "Pull Requests". The latter existed before, but the term technically feels a little wrong (you ask someone to pull your changes from a remote, which is not really remote but placed on the same server. And if accepted, the other party goes to your changes to get them in. This kinda creates a knot in my head. Why not say "Proposed Changes" which doesn't involve multiple virtual roundtrips).

Amen

> […]
> * consider renaming pull requests, e.g. to "Proposed Changes" or "Patches" … ?!

"Patches" certainly comes to mind, but seems like a suboptimal choice given its association with patch files, which are of course very related but also different, and because the non-technological sense of patch is something which fixes something broken, which is not the only purpose of proposed changes.

I very much prefer "Proposed changes", but then that's significantly longer and poorly abbreviable. Also, is a merge request _a proposed change_ or _proposed change**s**_? Also, "proposed changes" sounds like they are pending acceptance; if we want to say discuss statistics about those which have already been accepted, or discuss those which haven't been proposed yet, and avoid the pluralization issue, "Change proposal(s)" would be better. But "Source change proposal" (SCP) would be more precise and abbreviable.
Chealer
referenced this issue from forgejo/forgejo
2025-01-29 19:00:14 +01:00
ITS: Term "issue" conflated with tickets (issue reports), in documentation (The Basics of Issue Tracking) and elsewhere
#6697
fnetX
commented
2025-01-29 22:46:58 +01:00
Author
Owner
Copy link
"Changesets" comes to my mind as well.
"Changesets" comes to my mind as well.
Chealer
commented
2025-01-30 05:43:36 +01:00
Copy link
According to the English Wikipedia, a changeset is a commit. "changeset" does not carry the notion of proposition.
According to the English Wikipedia, a changeset is a commit. "changeset" does not carry the notion of proposition.
Snoweuph
commented
2025-01-30 12:09:53 +01:00
Copy link
I mean generating a patchfile for git is easy (and also possible per GUI in a lot of IDES), couldnt we do a PR from patchfiles option, wheresombody uploads git patch files?
I mean generating a patchfile for git is easy (and also possible per GUI in a lot of IDES), couldnt we do a PR from patchfiles option, wheresombody uploads git patch files?
smxi
commented
2025-01-30 23:32:34 +01:00
Copy link
I sympathize by the way with the difficulty of finding the right words for actions. I have that issue in inxi often, and it has taken me several iterations to finally come up with the word that is best for the data or section key name. This is not trivial because it often requires really asking myself, and others, what is actually happening, and what words best reflect that.
I've found it useful to ask others for suggestions, then to add my own, and try living with various ones for a while until it gets more clear if it is the right direction or not.
In this case, replacing 'fork' with 'clone' is easy,, because that is what is being done, it's how git describes it, it was only github making a silly misuse of the term 'fork' that created this issue.
Reading the latest, it hit me, what is a clone with activity? It's an active clone, but I suspect the vast majority of active clones involved only a change or two, or at most, a single changeset. Since in my experience, most clones are inactive, or rather, passive, active states would be in the minority, and active ones can be determined simply by a clone getting activity, over x time, and if no activity, it becomes a simple dormant clone again.
A fork is something that probably happens to most projects either never or 1 time, with a few rare exceptions when people are trying to salvage a dead or non receptive project, where you might see a few efforts at forking, but in general, only 1 will survive because that's just the reality of available man hours in FOSS. Libreoffice is the fork of OpenOffice, and is the living branch, though openoffice gets light activity, so that's a true fork. But this is not common, and could be indicated by a combination of a checkbox on initial clone, a name change of project, which often happens with forks, and ongoing activity. Probably not wise to have a checkbox since github users would think they are forking when they are not forking.
To me, a true fork will first of all only clone the initial codebase from some commit point one time, then move on as a new project. Usually with a new name, though I don't know how common that is.
Just to throw out some more things, and trying to remember what is really happening, both push request and pull request make some sense, in the first case, a person pushes some proposed changes to the project, and is requesting you accept, or least review an comment on them.
This is what I think most unsolicited patches actually are, they are pushes to the repo, and you look at it, and accept, partially accept, or reject them.
Likewise, a pull request is pretty much the same thing, except they are requesting you pull their changes into the repo. If I were to try to distinguish, I'd lean towards a pull request being more like something in the linux kernel, where a contributor who is already accepted makes the patch, and requests it will be pulled by a core maintainer.
Again, these are just random ways I have of thinking of this, but to me, unsolicited changes that might not even follow the rules are different from someone who is a contributor already pushing changes to be pulled by the maintainer of that section of code.
Typing this out, to me, there's really nothing wrong with the term Pull or Push request, they basically define what is happening, and maybe github more or less got this one right? Or close enough.
Since most PR I get can't be used because they didn't read the rules, but will be used as patches by me if valid, from my limited area of experience, it feels like someone out of the blue pushing something to the repo is not the same as someone in a project requesting code be pulled into it. But this is really just semantics.
For example, right now, a long time contributor to sgfxi has made a pull request, and that's what I will do, pull his code after reviewing it, because I know he tends to get it fairly right.
Reading some of the notions above, for example, what is a change proposal, if in code form? it's going to be either accept a push or a pull request. Which by definition are changes, so it's not really necessary to say that. A patch that changes nothing is nothing, so all push/pull/change etc are going to change something.
But I know for me, there are 2 different events, one is something from a contributor, that I pull because I trust them. The other is something someone pushes or offers to push, but which I probably don't want in that form for some reason.
Anyway, I've found it helpful to toss out some options and explain why they are options, and maybe that leads to something clicking in someone's head and suddenly, thinking, ah, ok, wait, now it makes sense to me. And it has to make sense to the project, not to someone like me outside of your project.
whatever the case, keep up the great work, thanks for doing this stuff.
I sympathize by the way with the difficulty of finding the right words for actions. I have that issue in inxi often, and it has taken me several iterations to finally come up with the word that is best for the data or section key name. This is not trivial because it often requires really asking myself, and others, what is actually happening, and what words best reflect that.

I've found it useful to ask others for suggestions, then to add my own, and try living with various ones for a while until it gets more clear if it is the right direction or not.

In this case, replacing 'fork' with 'clone' is easy,, because that is what is being done, it's how git describes it, it was only github making a silly misuse of the term 'fork' that created this issue.

Reading the latest, it hit me, what is a clone with activity? It's an active clone, but I suspect the vast majority of active clones involved only a change or two, or at most, a single changeset. Since in my experience, most clones are inactive, or rather, passive, active states would be in the minority, and active ones can be determined simply by a clone getting activity, over x time, and if no activity, it becomes a simple dormant clone again.

A fork is something that probably happens to most projects either never or 1 time, with a few rare exceptions when people are trying to salvage a dead or non receptive project, where you might see a few efforts at forking, but in general, only 1 will survive because that's just the reality of available man hours in FOSS. Libreoffice is the fork of OpenOffice, and is the living branch, though openoffice gets light activity, so that's a true fork. But this is not common, and could be indicated by a combination of a checkbox on initial clone, a name change of project, which often happens with forks, and ongoing activity. Probably not wise to have a checkbox since github users would think they are forking when they are not forking.

To me, a true fork will first of all only clone the initial codebase from some commit point one time, then move on as a new project. Usually with a new name, though I don't know how common that is.

Just to throw out some more things, and trying to remember what is really happening, both push request and pull request make some sense, in the first case, a person pushes some proposed changes to the project, and is requesting you accept, or least review an comment on them.

This is what I think most unsolicited patches actually are, they are pushes to the repo, and you look at it, and accept, partially accept, or reject them.

Likewise, a pull request is pretty much the same thing, except they are requesting you pull their changes into the repo. If I were to try to distinguish, I'd lean towards a pull request being more like something in the linux kernel, where a contributor who is already accepted makes the patch, and requests it will be pulled by a core maintainer.

Again, these are just random ways I have of thinking of this, but to me, unsolicited changes that might not even follow the rules are different from someone who is a contributor already pushing changes to be pulled by the maintainer of that section of code.

Typing this out, to me, there's really nothing wrong with the term Pull or Push request, they basically define what is happening, and maybe github more or less got this one right? Or close enough.

Since most PR I get can't be used because they didn't read the rules, but will be used as patches by me if valid, from my limited area of experience, it feels like someone out of the blue pushing something to the repo is not the same as someone in a project requesting code be pulled into it. But this is really just semantics.

For example, right now, a long time contributor to sgfxi has made a pull request, and that's what I will do, pull his code after reviewing it, because I know he tends to get it fairly right.

Reading some of the notions above, for example, what is a change proposal, if in code form? it's going to be either accept a push or a pull request. Which by definition are changes, so it's not really necessary to say that. A patch that changes nothing is nothing, so all push/pull/change etc are going to change something.

But I know for me, there are 2 different events, one is something from a contributor, that I pull because I trust them. The other is something someone pushes or offers to push, but which I probably don't want in that form for some reason.

Anyway, I've found it helpful to toss out some options and explain why they are options, and maybe that leads to something clicking in someone's head and suddenly, thinking, ah, ok, wait, now it makes sense to me. And it has to make sense to the project, not to someone like me outside of your project.

whatever the case, keep up the great work, thanks for doing this stuff.
wolftune
commented
2025-01-31 00:18:30 +01:00
Copy link
Strong
agreement with the idea of using "clone" (which is the Git term!)
"fork" is best used to mean taking a project in a different direction (i.e. cloning plus changing) with the
common
implication that the changes may not get merged back in
Anyway, especially since the
fork
of Forgejo is stronger now than it was before (harder) relating to Gitea, I'm copying my note from there (which above I had only
linked
):
An alternative or complementary design (potentially in addition to a "sync" function discussed in
forgejo/forgejo#471
):
Allow a
non-team-member
to edit files from a repository
currently the edit function is just grayed out
When they are making their commit, only offer the option of committing on their fork (making a fork if it doesn't exist yet)
Default to making it on a branch with a new name (not to main)
Offer the option of opening a pull-request from their fork/branch to the origin/main
Put another way: instead of blocking users from editing directly on projects where they don't have permission to open branches, the user experience should be this: while the user is looking at a project, just let them edit and automatically
make
the edit go to a new branch on their fork (prompting them to confirm the creation of a fork if none was yet made).
**Strong** agreement with the idea of using "clone" (which is the Git term!)

"fork" is best used to mean taking a project in a different direction (i.e. cloning plus changing) with the *common* implication that the changes may not get merged back in

Anyway, especially since the **fork** of Forgejo is stronger now than it was before (harder) relating to Gitea, I'm copying my note from there (which above I had only *linked*):

> An alternative or complementary design (potentially in addition to a "sync" function discussed in https://codeberg.org/forgejo/forgejo/issues/471 ):
> - Allow a *non-team-member* to edit files from a repository
> - currently the edit function is just grayed out
> - When they are making their commit, only offer the option of committing on their fork (making a fork if it doesn't exist yet)
> - Default to making it on a branch with a new name (not to main)
> - Offer the option of opening a pull-request from their fork/branch to the origin/main
> Put another way: instead of blocking users from editing directly on projects where they don't have permission to open branches, the user experience should be this: while the user is looking at a project, just let them edit and automatically *make* the edit go to a new branch on their fork (prompting them to confirm the creation of a fork if none was yet made).
fnetX
commented
2025-01-31 01:23:30 +01:00
Author
Owner
Copy link
Sorry, this discussion is getting entirely off-topic. The goal of our redesigned Git workflow is to not require forks or clones or whatever on the server at all. There is no need to change the term for something that we want to get rid of entirely,
Sorry, this discussion is getting entirely off-topic. The goal of our redesigned Git workflow is to not require forks or clones or whatever on the server at all. There is no need to change the term for something that we want to get rid of entirely,
wolftune
commented
2025-01-31 06:44:11 +01:00
Copy link
Sorry, the recent noise from this discussion got me off of seeing the bigger context.
I have some specific perspectives to share back on track with the main point. Although I'm a contributor to software (especially small fixes, bug reporting, documentation), my primary use of Git and of Codeberg is not program code that mostly programmers would be seeing. I think the value of Git and Codeberg and Forgejo offer amazing potential to other types of projects including journalism, education, and other written types of works.
The comparison to make is to wikis. In general, the contribution process to a wiki is far easier. The problem in both extremes: some people hesitate to contribute because they are directly writing to a single-line history, and they feel uncomfortable, lacking confidence or authority etc.; but other people make changes too thoughtlessly because they are less self-conscious and more willing to just do things (but their changes aren't always good). Git (or any other DVCS) offers so many advantages here. And the PR-review process is essential.
So, for the workflow I need to best facilitate the most effective contributions, we
cannot
assume programmers who are used to working in the terminal and such and using Git locally.
What would be the ideal vision for me:
UI allows editing files and then going right to opening PRs for review even for someone with
zero
Git understanding
only requirement would be making an account at the host (such as at Codeberg); ideally not even that except in today's world there's no way to allow anonymous arbitrary contributions without a ton of bots like Wikipedia uses to filter bad submissions
Branching still happens such that the Git functions of multiple commits (including by multiple authors) can be used to update PRs
Also, making commits
without
opening a PR makes sense in order to allow people to start working on something without pulling anyone else's attention before they want it
So, I think the proposals at the base of this discussion are in the right direction. I support the ideas of having branches that have meaningful names and are filtered. So, a project could allow users who aren't project members to make branches in these ways such that the branches aren't just mixed with the branches that the project members see in their normal working list.
I think in this context, cloning and forking are unrelated. People can clone repos locally when they understand how to work that way and prefer to. People can fork a project because they care to actually have their own project they manage separately and take in other directions. These things shouldn't be needed at all in order for contributors to submit some input to a main project. Branching is all we need to segregate some work for a new contribution.
So, I strongly support the overall direction this discussion is aiming for. I hope my use case is helpful in terms of user-research (and I'm happy to discuss further; I actively work with contributors who are entirely new to this way of working and are not programmers).
Sorry, the recent noise from this discussion got me off of seeing the bigger context.

I have some specific perspectives to share back on track with the main point. Although I'm a contributor to software (especially small fixes, bug reporting, documentation), my primary use of Git and of Codeberg is not program code that mostly programmers would be seeing. I think the value of Git and Codeberg and Forgejo offer amazing potential to other types of projects including journalism, education, and other written types of works.

The comparison to make is to wikis. In general, the contribution process to a wiki is far easier. The problem in both extremes: some people hesitate to contribute because they are directly writing to a single-line history, and they feel uncomfortable, lacking confidence or authority etc.; but other people make changes too thoughtlessly because they are less self-conscious and more willing to just do things (but their changes aren't always good). Git (or any other DVCS) offers so many advantages here. And the PR-review process is essential.

So, for the workflow I need to best facilitate the most effective contributions, we *cannot* assume programmers who are used to working in the terminal and such and using Git locally.

What would be the ideal vision for me:

- UI allows editing files and then going right to opening PRs for review even for someone with *zero* Git understanding
- only requirement would be making an account at the host (such as at Codeberg); ideally not even that except in today's world there's no way to allow anonymous arbitrary contributions without a ton of bots like Wikipedia uses to filter bad submissions
- Branching still happens such that the Git functions of multiple commits (including by multiple authors) can be used to update PRs
- Also, making commits *without* opening a PR makes sense in order to allow people to start working on something without pulling anyone else's attention before they want it

So, I think the proposals at the base of this discussion are in the right direction. I support the ideas of having branches that have meaningful names and are filtered. So, a project could allow users who aren't project members to make branches in these ways such that the branches aren't just mixed with the branches that the project members see in their normal working list.

I think in this context, cloning and forking are unrelated. People can clone repos locally when they understand how to work that way and prefer to. People can fork a project because they care to actually have their own project they manage separately and take in other directions. These things shouldn't be needed at all in order for contributors to submit some input to a main project. Branching is all we need to segregate some work for a new contribution.

So, I strongly support the overall direction this discussion is aiming for. I hope my use case is helpful in terms of user-research (and I'm happy to discuss further; I actively work with contributors who are entirely new to this way of working and are not programmers).
fnetX
referenced this issue
2025-02-05 17:42:10 +01:00
FOSDEM 2025 impressions
#290
fnetX
referenced this issue
2025-02-05 17:43:28 +01:00
FOSDEM 2025 impressions
#290
mahlzahn
referenced this issue
2025-02-05 22:03:24 +01:00
Fork own repository
#286
richardhuxton
commented
2025-03-20 18:44:10 +01:00
Copy link
I'm just a random minor forgejo user who has happened across this discussion, but I'm surprised that two obvious points haven't been made.
Firstly - 99% of the developers who interact with forgejo will be at least passingly familiar with github and for better or worse most will be used to operating in that way. Not being able to work that way is setting up a barrier to them using forgejo.
Secondly - anything that lets random accounts post stuff to my repo makes it trivial for trolls to cause me trouble. It doesn't even have to be something owned by Disney/Nintendo or kiddie-porn. A file-full of code under an incompatible licence ought to be enough. Even if the tools to clean up are easy to use, it's still more effort and I'll have to let anyone who has pulled those changes know too.
I'm just a random minor forgejo user who has happened across this discussion, but I'm surprised that two obvious points haven't been made.

Firstly - 99% of the developers who interact with forgejo will be at least passingly familiar with github and for better or worse most will be used to operating in that way. Not being able to work that way is setting up a barrier to them using forgejo.

Secondly - anything that lets random accounts post stuff to my repo makes it trivial for trolls to cause me trouble. It doesn't even have to be something owned by Disney/Nintendo or kiddie-porn. A file-full of code under an incompatible licence ought to be enough. Even if the tools to clean up are easy to use, it's still more effort and I'll have to let anyone who has pulled those changes know too.
Kwonunn
commented
2025-03-20 18:54:09 +01:00
Member
Copy link
@richardhuxton
wrote in
#131 (comment)
Firstly - 99% of the developers who interact with forgejo will be at least passingly familiar with github and for better or worse most will be used to operating in that way. Not being able to work that way is setting up a barrier to them using forgejo.
Secondly - anything that lets random accounts post stuff to my repo makes it trivial for trolls to cause me trouble. It doesn't even have to be something owned by Disney/Nintendo or kiddie-porn. A file-full of code under an incompatible licence ought to be enough. Even if the tools to clean up are easy to use, it's still more effort and I'll have to let anyone who has pulled those changes know too.
There will still be a concept of "Pull Requests" (although they may be named differently). It will not be possible for random people to push things to your repository any more than they can now.
The difference between now and then is that instead of having to fork the target repository and push to that, and
then
making a pull request, now you can push directly to a special reference in the target repository and make a pull request from there. Random accounts will not be able to push things to repositories for which they do not have write access.
@richardhuxton wrote in https://codeberg.org/forgejo/discussions/issues/131#issuecomment-3094688:

> Firstly - 99% of the developers who interact with forgejo will be at least passingly familiar with github and for better or worse most will be used to operating in that way. Not being able to work that way is setting up a barrier to them using forgejo.
> Secondly - anything that lets random accounts post stuff to my repo makes it trivial for trolls to cause me trouble. It doesn't even have to be something owned by Disney/Nintendo or kiddie-porn. A file-full of code under an incompatible licence ought to be enough. Even if the tools to clean up are easy to use, it's still more effort and I'll have to let anyone who has pulled those changes know too.

There will still be a concept of "Pull Requests" (although they may be named differently). It will not be possible for random people to push things to your repository any more than they can now.

The difference between now and then is that instead of having to fork the target repository and push to that, and *then* making a pull request, now you can push directly to a special reference in the target repository and make a pull request from there. Random accounts will not be able to push things to repositories for which they do not have write access.
richardhuxton
commented
2025-03-21 12:18:38 +01:00
Copy link
@Kwonunn
wrote in
#131 (comment)
There will still be a concept of "Pull Requests" (although they may be named differently). It will not be possible for random people to push things to your repository any more than they can now.
Surely that is just a "patch", which is how you would be working via email (and nothing wrong with that).
But, if we scroll through this discussion:
you push the branch back to the repo which enforces a certain namespace like from_username/original_branchname, or a similar prefix which is unlikely to conflict
these special branches are not included in normal clones from the repo but can only be fetched with a special command, like git fetch origin u_username/branch/head:{local_branch}
and:
So, I think the proposals at the base of this discussion are in the right direction. I support the ideas of having branches that have meaningful names and are filtered. So, a project could allow users who aren't project members to make branches in these ways such that the branches aren't just mixed with the branches that the project members see in their normal working list.
In these previous posts it does very much look like other-people's changes are ending up in my repo. If they aren't then I have no idea what they talking about. They clearly aren't talking about a "local clone" on a user's machine or a "fork" (separate copy of a repo on the same forgejo instance), because those are the things that this discussion is seeking an alternative to.
@Kwonunn wrote in https://codeberg.org/forgejo/discussions/issues/131#issuecomment-3094730:
> There will still be a concept of "Pull Requests" (although they may be named differently). It will not be possible for random people to push things to your repository any more than they can now.

Surely that is just a "patch", which is how you would be working via email (and nothing wrong with that).

But, if we scroll through this discussion:

> > you push the branch back to the repo which enforces a certain namespace like from_username/original_branchname, or a similar prefix which is unlikely to conflict
> >
> > these special branches are not included in normal clones from the repo but can only be fetched with a special command, like git fetch origin u_username/branch/head:{local_branch}

and:

> > So, I think the proposals at the base of this discussion are in the right direction. I support the ideas of having branches that have meaningful names and are filtered. So, a project could allow users who aren't project members to make branches in these ways such that the branches aren't just mixed with the branches that the project members see in their normal working list.

In these previous posts it does very much look like other-people's changes are ending up in my repo. If they aren't then I have no idea what they talking about. They clearly aren't talking about a "local clone" on a user's machine or a "fork" (separate copy of a repo on the same forgejo instance), because those are the things that this discussion is seeking an alternative to.
Kwonunn
commented
2025-03-21 12:26:22 +01:00
Member
Copy link
@richardhuxton
It is true that the user will be pushing towards your repository, eg doing something like
git push -u git@codeberg.org:forgejo/forgejo pr/update-readme
. However, Forgejo will catch this push and instead of putting it in the repository like normal, it will be stored as a pull request. That means it will not show up on the main repository page, it will not show up in the branch listing, and it will not be clonable.
Only once the person who pushed the branch has made a pull request, the branch will become visible to other users, and only in the pull requests tab.
How this is going to work behind the scenes exactly is something i'm still working out, but I completely understand that you don't want random people pushing things to your repository, and that is not the goal of this feature.
@richardhuxton

It is true that the user will be pushing towards your repository, eg doing something like `git push -u git@codeberg.org:forgejo/forgejo pr/update-readme`. However, Forgejo will catch this push and instead of putting it in the repository like normal, it will be stored as a pull request. That means it will not show up on the main repository page, it will not show up in the branch listing, and it will not be clonable.

Only once the person who pushed the branch has made a pull request, the branch will become visible to other users, and only in the pull requests tab.

How this is going to work behind the scenes exactly is something i'm still working out, but I completely understand that you don't want random people pushing things to your repository, and that is not the goal of this feature.
Kwonunn
commented
2025-03-21 12:31:39 +01:00
Member
Copy link
For reference, something quite similar to this already happens when you use
AGit
. We would essentially be building a more usable system on top of that idea.
For reference, something quite similar to this already happens when you use [AGit](https://forgejo.org/docs/latest/user/agit-support/). We would essentially be building a more usable system on top of that idea.
richardhuxton
commented
2025-03-21 13:06:07 +01:00
Copy link
Ah, now I see. There will be (something like) a hidden repo where the "contribution requests" end up. Then forgejo's code will let different users interact with that in a controlled manner. As the "target repo" owner I'll be able to pull a change from that into a branch in my repo and merge it if I want. Thanks - that clears it up.
Ah, now I see. There will be (something like) a hidden repo where the "contribution requests" end up. Then forgejo's code will let different users interact with that in a controlled manner. As the "target repo" owner I'll be able to pull a change from that into a branch in my repo and merge it if I want. Thanks - that clears it up.
fnetX
commented
2025-03-21 14:29:43 +01:00
Author
Owner
Copy link
Exactly. The primary issue with AGit is that it uses references, which Git doesn't remember out of the box. So you manually need to remember where you pushed a change to, while Git conveniently allows to remember that for real branches.
BTW, your "impersonation" thing with branches is actually possible. This
commit in Forgejo
is not actually part of the codebase. It comes from a fork and is contained in a PR. GitHub allowed the same (and probably still allows, but I didn't check recently). There was a lot of controversy around this where people spoofed Linus Torvald's commits and made it look like they were part of the Linux kernel, while they were actually not. It's very hard to prevent this.
Exactly. The primary issue with AGit is that it uses references, which Git doesn't remember out of the box. So you manually need to remember where you pushed a change to, while Git conveniently allows to remember that for real branches.

BTW, your "impersonation" thing with branches is actually possible. This [commit in Forgejo](https://codeberg.org/forgejo/forgejo/commit/aa0daf367b37729f8823ff0d30add16d8c0f86c2) is not actually part of the codebase. It comes from a fork and is contained in a PR. GitHub allowed the same (and probably still allows, but I didn't check recently). There was a lot of controversy around this where people spoofed Linus Torvald's commits and made it look like they were part of the Linux kernel, while they were actually not. It's very hard to prevent this.
fnetX
referenced this issue from forgejo/website
2025-04-29 17:07:22 +02:00
Monthly Update for April 2025
#571
brechtvl
commented
2025-05-01 21:19:53 +02:00
Copy link
Perhaps an interesting middle ground may to have more lightweight forks (called "contributions"?). This would mainly be a user interface change, sharing most of the code under the hood.
The fork would only contain your own branches by default, avoiding any need to sync. Units like issues and releases would be disabled. You'd still be able to browse code, but you don't need a description, README, language stats, etc.
The home page of the fork would list branches and their corresponding pull requests and review status, and not much else. Effectively it would be a convenient overview of your contributions to the base repository, and your work in progress branches.
This would need to integrate well with online editing (see also
).
Duplicated storage seems solvable. For example, garbage collection on forks could re-clone the base repository, add the branches from the fork, and only then run git gc. That way the existing hard links mechanism would be more effective.
The reason I prefer this over an AGit-like workflow is:
Storing branches that are not PRs for:
Sharing code between computers (home - work, testing changes on different OSes)
Sharing work in progress branches with others
Collaborating with other developers on a branch
Backup
Using Git GUIs that understand remotes and GitHub-like workflows.
At Blender we used to have a more AGit-like workflow in Phabricator, and often developers (including myself) would have forks on GitLab or GitHub for these use cases.
Perhaps an interesting middle ground may to have more lightweight forks (called "contributions"?). This would mainly be a user interface change, sharing most of the code under the hood.

* The fork would only contain your own branches by default, avoiding any need to sync. Units like issues and releases would be disabled. You'd still be able to browse code, but you don't need a description, README, language stats, etc.
* The home page of the fork would list branches and their corresponding pull requests and review status, and not much else. Effectively it would be a convenient overview of your contributions to the base repository, and your work in progress branches.
* This would need to integrate well with online editing (see also https://github.com/go-gitea/gitea/pull/34240).
* Duplicated storage seems solvable. For example, garbage collection on forks could re-clone the base repository, add the branches from the fork, and only then run git gc. That way the existing hard links mechanism would be more effective.

The reason I prefer this over an AGit-like workflow is:
* Storing branches that are not PRs for:
* Sharing code between computers (home - work, testing changes on different OSes)
* Sharing work in progress branches with others
* Collaborating with other developers on a branch
* Backup
* Using Git GUIs that understand remotes and GitHub-like workflows.

At Blender we used to have a more AGit-like workflow in Phabricator, and often developers (including myself) would have forks on GitLab or GitHub for these use cases.
fnetX
commented
2025-05-02 10:47:23 +02:00
Author
Owner
Copy link
@brechtvl
Also see
forgejo/design#7
which contains another idea.
@brechtvl Also see https://codeberg.org/forgejo/design/issues/7 which contains another idea.
fnetX
commented
2025-05-02 10:48:48 +02:00
Author
Owner
Copy link
And as you probably read, the goal is to NOT have an AGit workflow due to its limitations, but rather a way to push work without the downsides of forks.
And as you probably read, the goal is to NOT have an AGit workflow due to its limitations, but rather a way to push work without the downsides of forks.
Kladky
commented
2025-05-02 11:12:04 +02:00
Copy link
Could we please get a summary of the limitations? I haven't experienced any so far, so I am curious as to what they are.
Could we please get a summary of the limitations? I haven't experienced any so far, so I am curious as to what they are.
fnetX
commented
2025-05-02 11:18:12 +02:00
Author
Owner
Copy link
I think the most important ones are:
No way to collaborate on code, e.g. by creating PRs to other PRs.
You need to remember the push string, which is a little long. For normal branches, you set up tracking (Git even does it automatically), so you can just do
git push
. If you inadvertently do
git push
with AGit and have no branch protection, you override the remote state.
It's not possible to show work and proof of concepts without creating a PR.
I think the most important ones are:

* No way to collaborate on code, e.g. by creating PRs to other PRs.
* You need to remember the push string, which is a little long. For normal branches, you set up tracking (Git even does it automatically), so you can just do `git push`. If you inadvertently do `git push` with AGit and have no branch protection, you override the remote state.
* It's not possible to show work and proof of concepts without creating a PR.
Kladky
commented
2025-05-18 16:21:29 +02:00
Copy link
On the second point, the Forgejo docs have a method to automatically push to the Agit pull request without remembering the pathspec:
Besides that, the other points seem like they could be fixed with changes to the Agit workflow, rather than completely replacing it with something else. But hey, if you all manage to think of something more convenient than Agit (maybe something like automatically creating scoped branches if you don't have write access to the repo when you try to push a branch that doesn't exist yet. For git you can have those branches only be accessible from fetching a pathspec that makes it clear that they are external. Then for the web page, have a tab in the branches section where you can view "contribution" branches).
On the second point, the Forgejo docs have a method to automatically push to the Agit pull request without remembering the pathspec: https://forgejo.org/docs/latest/user/agit-support/#changing-the-default-push-method

Besides that, the other points seem like they could be fixed with changes to the Agit workflow, rather than completely replacing it with something else. But hey, if you all manage to think of something more convenient than Agit (maybe something like automatically creating scoped branches if you don't have write access to the repo when you try to push a branch that doesn't exist yet. For git you can have those branches only be accessible from fetching a pathspec that makes it clear that they are external. Then for the web page, have a tab in the branches section where you can view "contribution" branches).
fnetX
referenced this issue from forgejo/forgejo
2025-06-07 23:18:26 +02:00
feat: Add the button "Edit the file in your fork"
#8045
fnetX
referenced this issue from forgejo/sustainability
2025-07-15 00:23:31 +02:00
NLnet funding for next federation step ?
#108
jerger
referenced this issue from forgejo/sustainability
2025-07-15 13:25:40 +02:00
NLnet funding for next federation step ?
#108
fnetX
referenced this issue from forgejo/forgejo
2025-07-26 15:05:30 +02:00
feat: Add new upstream branches to Sync Fork options
#8672
VewDev
commented
2025-10-25 09:51:41 +02:00
Copy link
I just came across this thread, and wanted to add my two cents on this.
the concept of "Pull Requests". The latter existed before, but the term technically feels a little wrong (you ask someone to pull your changes from a remote, which is not really remote but placed on the same server. And if accepted, the other party goes to your changes to get them in. This kinda creates a knot in my head. Why not say "Proposed Changes" which doesn't involve multiple virtual roundtrips).
It may have been mentioned before, but a rename to "Merge Requests" could be in place.
For the person creating the PR, it conveys that they are requesting to merge their changes into upstream.
For the person receiving/reviewing the PR, it conveys that this is a request to merge the changes into their repo.
This is also the naming GitLab currently uses for their equivalent of PRs.
I just came across this thread, and wanted to add my two cents on this.

> the concept of "Pull Requests". The latter existed before, but the term technically feels a little wrong (you ask someone to pull your changes from a remote, which is not really remote but placed on the same server. And if accepted, the other party goes to your changes to get them in. This kinda creates a knot in my head. Why not say "Proposed Changes" which doesn't involve multiple virtual roundtrips).

It may have been mentioned before, but a rename to "Merge Requests" could be in place.

- For the person creating the PR, it conveys that they are requesting to merge their changes into upstream.
- For the person receiving/reviewing the PR, it conveys that this is a request to merge the changes into their repo.

This is also the naming GitLab currently uses for their equivalent of PRs.
fnetX
referenced this issue from forgejo/forgejo
2025-10-26 02:45:24 +01:00
feat: Add preference to select default value of "Allow edits from maintainers"
#6855
fnetX
referenced this issue from forgejo/website
2025-10-31 00:20:36 +01:00
Monthly Report for October 2025
#654
fnetX
referenced this issue from forgejo/website
2025-10-31 03:46:11 +01:00
Monthly Report for October 2025
#654
diraneyya
referenced this issue
2025-11-12 09:45:50 +01:00
Discussion: Explicit Merge Intent for Pull Requests
#416
forgejo-actions
referenced this issue from forgejo/website
2025-11-27 18:11:32 +01:00
Dead links report
#529
milahu
commented
2026-01-07 13:08:49 +01:00
Copy link
this kind of deduplication is a good idea...
until the repo owner decides to remove the repo → data loss
forks are useful to create backup copies of a repo (archive snapshots of a repo)
for space-efficient forks, we would need
forgejo/forgejo#4957
assuming we would completely remove forks
then people could still create copies of repos, without any deduplication
this kind of deduplication is a good idea...
until the repo owner decides to remove the repo → data loss

forks are useful to create backup copies of a repo (archive snapshots of a repo)

for space-efficient forks, we would need https://codeberg.org/forgejo/forgejo/issues/4957

assuming we would completely remove forks
then people could still create copies of repos, without any deduplication
eschwartz
commented
2026-01-07 14:51:50 +01:00
Copy link
I don't think anyone has suggested to fully remove the ability to create forks.
It is foolish in the extreme to rely on random users creating random untrusted forks as a defense mechanism against software developers removing their works from the internet. Use
instead, please.
I don't think anyone has suggested to fully remove the ability to create forks.

It is foolish in the extreme to rely on random users creating random untrusted forks as a defense mechanism against software developers removing their works from the internet. Use https://softwareheritage.org instead, please.
milahu
commented
2026-01-07 15:44:54 +01:00
Copy link
forks should not be treated as a second-class feature
I don't think anyone has suggested to fully remove the ability to create forks.
i was referring to
There are numerous issues with forks. I propose not to invest any human resources into solving them, and instead close the following issues
even if fork users become a minority, these issues still persist
and fork users will be interested in solving these issues
"not my problem, so we should close these issues"
ignoring issues != solving issues
It is foolish in the extreme to rely on random users creating random untrusted forks as a defense mechanism against software developers removing their works from the internet.
the problem is, you dont know in advance which repos will be removed in the future.
example:
was removed about a year ago
was a fork i could use as a backup
meanwhile, the owner restored the repo
example:
i "abuse" the fork feature to create read-only snapshots of my git repos
on tor-hidden gitea instances, to make it harder for my enemies to censor my repos
(censorship-resistance by redundancy)
deferring the solution to softwareheritage.org
just moves the problem to another single point of failure (on the clearnet)

forks should not be treated as a second-class feature

> I don't think anyone has suggested to fully remove the ability to create forks.

i was referring to

> There are numerous issues with forks. I propose not to invest any human resources into solving them, and instead close the following issues

even if fork users become a minority, these issues still persist
and fork users will be interested in solving these issues

"not my problem, so we should close these issues"
ignoring issues != solving issues

> It is foolish in the extreme to rely on random users creating random untrusted forks as a defense mechanism against software developers removing their works from the internet.

the problem is, you dont know in advance which repos will be removed in the future.

example:
meanwhile, the owner restored the repo

example:
i "abuse" the fork feature to create read-only snapshots of my git repos
on tor-hidden gitea instances, to make it harder for my enemies to censor my repos
(censorship-resistance by redundancy)

deferring the solution to softwareheritage.org
just moves the problem to another single point of failure (on the clearnet)

Kwonunn
commented
2026-01-07 15:54:33 +01:00
Member
Copy link
The basic forking functionality isn't going anywhere. We just want to explore a different way for people to contribute to large public repositories that doesn't require them to fork the entire repository.
The basic forking functionality isn't going anywhere. We just want to explore a different way for people to contribute to large public repositories that doesn't require them to fork the entire repository.
forgejo-actions
referenced this issue from forgejo/website
2026-01-08 18:02:11 +01:00
Dead links report
#529
litchipi
commented
2026-01-12 11:11:04 +01:00
Member
Copy link
Sorry, I was looking at
forgejo/forgejo#4957 (comment)
, isn't it clear that the focus is on getting rid of the forking system ?
Or is it only the "to contribute you need to fork" part of such system ?
Sorry, I was looking at https://codeberg.org/forgejo/forgejo/issues/4957#issuecomment-2182844 , isn't it clear that the focus is on getting rid of the forking system ?
Or is it only the "to contribute you need to fork" part of such system ?
Kwonunn
commented
2026-01-12 11:41:02 +01:00
Member
Copy link
Yeah, the goal of this project is not to remove forking altogether, but to make it possible to contribute to a public read-only project without having to fork it to create Pull Requests.
Forking itself will stay, as you can still use it to create an alternate version of a project (a fork in the way Forgejo is a fork of Gitea), or for other reasons.
Yeah, the goal of this project is not to remove forking altogether, but to make it possible to contribute to a public read-only project without having to fork it to create Pull Requests.

Forking itself will stay, as you can still use it to create an alternate version of a project (a fork in the way Forgejo is a fork of Gitea), or for other reasons.
fnetX
commented
2026-01-13 19:28:47 +01:00
Author
Owner
Copy link
To clear up the confusion: My goal is to provide an alternative to forking instead of fixing all the issues that forking currently has. We have to manage our human resources, and investing into a workflow that has a lot of issues by design is not a good idea IMHO.
The focus of the fork feature will be about "long-term" forks (e.g. Codeberg's soft-fork of Forgejo), but no longer as a contribution workflow.
However, I'd like to end the arguments in this thread. I don't see a good reason to discuss what will happen to forks after X before we get to doing X. It's a far future and we can discuss what to do with forks at other opportunities.
To clear up the confusion: My goal is to provide an alternative to forking instead of fixing all the issues that forking currently has. We have to manage our human resources, and investing into a workflow that has a lot of issues by design is not a good idea IMHO.
The focus of the fork feature will be about "long-term" forks (e.g. Codeberg's soft-fork of Forgejo), but no longer as a contribution workflow.

However, I'd like to end the arguments in this thread. I don't see a good reason to discuss what will happen to forks after X before we get to doing X. It's a far future and we can discuss what to do with forks at other opportunities.
to join this conversation.
No Branch/Tag specified
Branches
Tags
No results found.
No results found.
Labels
Clear labels
User research - Accessibility
Requires input about accessibility features, likely involves user testing.
User research - Blocked
Do not pick as-is! We are happy if you can help, but please coordinate with ongoing redesign in this area.
User research - Community
Community features, such as discovering other people's work or otherwise feeling welcome on a Forgejo instance.
User research - Config (instance)
Instance-wide configuration, authentication and other admin-only needs.
User research - Errors
How to deal with errors in the application and write helpful error messages.
User research - Filters
How filter and search is being worked with.
User research - Future backlog
The issue might be inspiring for future design work.
User research - Git workflow
AGit, fork-based and new Git workflow, PR creation etc
User research - Labels
Active research about Labels
User research - Moderation
Moderation Featuers for Admins are undergoing active User Research
User research - Needs input
Use this label to let the User Research team know their input is requested.
User research - Notifications/Dashboard
Research on how users should know what to do next.
User research - Rendering
Text rendering, markup languages etc
User research - Repo creation
Active research about the New Repo dialog.
User research - Repo units
The repo sections, disabling them and the "Add more" button.
User research - Security
User research - Settings (in-app)
How to structure in-app settings in the future?
No labels
User research - Accessibility
User research - Blocked
User research - Community
User research - Config (instance)
User research - Errors
User research - Filters
User research - Future backlog
User research - Git workflow
User research - Labels
User research - Moderation
User research - Needs input
User research - Notifications/Dashboard
User research - Rendering
User research - Repo creation
User research - Repo units
User research - Security
User research - Settings (in-app)
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
18 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".
No due date set.
Reference
forgejo/discussions#131
Reference in a new issue
No description provided.
Delete branch "%!s(
)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?