So we will likely want to have @ryanlerch ´ s input here since I know he has some (valid) concerns about this.

This needs further discussion before we merge

sounds right @pingou :smile:

Yeah, i'm leaning towards not allowing forks of forks, as it confuses things a lot for a user workflow that is not all that common.

The question I have really is: what would the specific workflow that would require someone to fork a fork? In pagure

Also, when I am looking at a fork, there is nothing in the namespace to tell me what fork it was originally forked from. Also, pagure currently only allows you to fork one projectname, so you wont be able to have a fork of the real project, as well as a fork of the fork of a project, will you?

so you wont be able to have a fork of the real project, as well as a fork of the fork of a project, will you?

No indeed.

what would the specific workflow that would require someone to fork a fork?

The only use-case I can think of is collaborating on a feature in a fork before pushing it upstream

So what's going to be ?

The only use-case I can think of is collaborating on a feature in a fork before pushing it upstream

Would a better solution here be to allow the user to make a branch of the branch in the fork that the want to collaborate on?

allow the user to make a branch of the branch in the fork that the want to collaborate on

Which basically leads to https://pagure.io/pagure/issue/46

So I'm going to close this one as wontfix and we'll consider it fixed when we manage to fix #46.

Thanks for the discussion folks :)