[Question] assign to PR users outside project #4066

New Issue

GiteaMirror · 2025-11-02T05:36:25-06:00

GiteaMirror commented

2025-11-02 05:36:25 -06:00

Originally created by @davydov-vyacheslav on GitHub (Oct 6, 2019).

I have a question about the process which is not usual and I haven’t found proper solution so far.

I have group of people who implement independent tasks. The tasks are the same for each person and the person can implement tasks in any order.

As of this I’d like to make it able to add to specific Pull-Requests certain person(s) (who have already implemented the task) who don’t have access to the project itself, because they may thief implementation of another tasks of certain person.

I suppose that this can’t be implemented (maybe due security reasons), so
Could someone share an idea of such process implementation, please?

Thanks,
Slava

Originally created by @davydov-vyacheslav on GitHub (Oct 6, 2019). I have a question about the process which is not usual and I haven’t found proper solution so far. I have group of people who implement independent tasks. The tasks are the same for each person and the person can implement tasks in any order. As of this I’d like to make it able to add to specific Pull-Requests certain person(s) (who have already implemented the task) who don’t have access to the project itself, because they may thief implementation of another tasks of certain person. I suppose that this can’t be implemented (maybe due security reasons), so Could someone share an idea of such process implementation, please? Thanks, Slava

GiteaMirror added the issue/stale label 2025-11-02 05:36:25 -06:00

GiteaMirror closed this issue

2025-11-02 05:36:25 -06:00

GiteaMirror commented

2025-11-02 05:36:26 -06:00

@guillep2k commented on GitHub (Oct 6, 2019):

Perhaps you can make each one of them work in a different fork? You'll have to create different "users" managed by you to make several forks. Then for each fork you can add one of those people as a collaborator.
Then you control how and when you update each fork or the main project.

@guillep2k commented on GitHub (Oct 6, 2019): Perhaps you can make each one of them work in a different fork? You'll have to create different "users" managed _by you_ to make several forks. Then for each fork you can add one of those people as a collaborator. Then you control how and when you update each fork or the main project.

GiteaMirror commented

2025-11-02 05:36:26 -06:00

@davydov-vyacheslav commented on GitHub (Oct 6, 2019):

@guillep2k thank you for reply!
So, each fork is managed separately and have different collaborators. That looks good.

The one question I have is the stage, when we're making the fork. If we're making the fork on demand, that means that the fork contains previous work (implementation of tasks A, B, C) which should not be shown to all of the other members (including the members who added to forked project to collaborate for task D).

So, in oder to have fully isolated tasks in forked project per task, we need to make forks ones the original project created, right?

@davydov-vyacheslav commented on GitHub (Oct 6, 2019): @guillep2k thank you for reply! So, each fork is managed separately and have different collaborators. That looks good. The one question I have is the stage, when we're making the fork. If we're making the fork on demand, that means that the fork contains previous work (implementation of tasks A, B, C) which should not be shown to all of the other members (including the members who added to forked project to collaborate for task D). So, in oder to have fully isolated tasks in forked project per task, we need to make forks ones the original project created, right?

GiteaMirror commented

2025-11-02 05:36:26 -06:00

@guillep2k commented on GitHub (Oct 6, 2019):

I'm not quite sure of what's exactly your use case (pehaps a classroom?) but yes, you need to fork the original project when it's "pristine" and never merge any PRs into it. You can have a third fork (invisible to other people) where you can merge PRs when you feel like it.

If you want to keep secrecy, I'd warn you that git (the tool behind Gitea) is too good retaining history, so "stomping" on old changes, deleting branches, etc. will not remove the old versions completely and they can be recovered using the right git commands, even in forks.

@guillep2k commented on GitHub (Oct 6, 2019): I'm not quite sure of what's exactly your use case (pehaps a classroom?) but yes, you need to fork the original project when it's "pristine" and never merge any PRs into it. You can have a third fork (invisible to other people) where you can merge PRs when you feel like it. If you want to keep secrecy, I'd warn you that git (the tool behind Gitea) is too good retaining history, so "stomping" on old changes, deleting branches, etc. will not remove the old versions completely and they can be recovered using the right git commands, even in forks.

GiteaMirror commented

2025-11-02 05:36:26 -06:00

@davydov-vyacheslav commented on GitHub (Oct 7, 2019):

@guillep2k

yes, this all about the classroom
yes, we're using git and I know about its history. Thats the main problem.

I have been investigating the possible flows for a while and got concluded that there is no way to create project-only-for-review with ability to view only separate PR. I've got one idea: we can create PR to separate / standalone code-review system (with particular authorities to particular review) , a-la reviewboard, but the problem I've got - I haven't seen any code review system which allows to review detached diff .....

Don't you know any?
Maybe you have an idea to improve the flow?

@davydov-vyacheslav commented on GitHub (Oct 7, 2019): @guillep2k 1) yes, this all about the classroom 2) yes, we're using git and I know about its history. Thats the main problem. I have been investigating the possible flows for a while and got concluded that there is no way to create project-only-for-review with ability to view only separate PR. I've got one idea: we can create PR to separate / standalone code-review system (with particular authorities to particular review) , a-la reviewboard, but the problem I've got - I haven't seen any code review system which allows to review detached diff ..... Don't you know any? Maybe you have an idea to improve the flow?

GiteaMirror commented

2025-11-02 05:36:26 -06:00

@guillep2k commented on GitHub (Oct 7, 2019):

If this is for a classroom, what I'd do with Gitea is the following:

Have a main pristine project, which is private. This one should never receive the students' work.
Add all students to a team ("students"), able to view code (no PR).
All users need to fork the main repository; their repos must be private as well.
The users need to add you as a collaborator (admin) of their forks.
Make their master branch protected, requiring at least one approving review for merging.
They can work in a development branch and make PRs for their own repository. You can approve, comment, request changes, etc.
Other students will never see their classmates' work (unless they share by other means, obviously).

@guillep2k commented on GitHub (Oct 7, 2019): If this is for a classroom, what I'd do with Gitea is the following: - Have a main *pristine* project, which is private. This one should never receive the students' work. - Add all students to a team ("students"), able to view code (no PR). - All users need to fork the main repository; *their* repos must be private as well. - The users need to add you as a collaborator (admin) of their forks. - Make their `master` branch *protected*, requiring at least one approving review for merging. - They can work in a development branch and make PRs for their own repository. You can approve, comment, request changes, etc. - Other students will never see their classmates' work (unless they share by other means, obviously).

GiteaMirror commented

2025-11-02 05:36:27 -06:00

@bagasme commented on GitHub (Oct 9, 2019):

@guillep2k Should the main (pristine) project repo also protect its master branch?

@bagasme commented on GitHub (Oct 9, 2019): @guillep2k Should the main (pristine) project repo also protect its `master` branch?

GiteaMirror commented

2025-11-02 05:36:27 -06:00

@guillep2k commented on GitHub (Oct 9, 2019):

@bagasme There's no need. Students need only read permissions, so protecting the branch from the teacher would be an unnecessary step IMHO.

@guillep2k commented on GitHub (Oct 9, 2019): @bagasme There's no need. Students need only read permissions, so protecting the branch from the teacher would be an unnecessary step IMHO.

GiteaMirror commented

2025-11-02 05:36:27 -06:00

@stale[bot] commented on GitHub (Dec 8, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Dec 8, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 05:36:27 -06:00

@stale[bot] commented on GitHub (Dec 22, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Dec 22, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 12:30:11 -06:00

[PR #4066] [MERGED] fix attachment ENABLED (#4064) #17224

Sign in to join this conversation.