[RFC] Support workflow with forks

[chshersh]

hit is very convenient when working with repos you own. But sometimes I still need to work with forks. I wonder, whether it's possible to make hit work with forks without sacrificing current UI.

My typical workflow with forks include:

1. Fork repo on GitHub.
2. Clone my fork (already can be achieved by hit clone command).
3. Do my work (all hit command work here)
4. Show all remotes (can be hit remotes command)
5. Add remote of the original repo (can be hit add-remote <owner>/<repo>)
6. Rebase on the branch from the remote repo (probably can patch hit fresh command so it understands hit fresh <remote>/<repo>).
7. Push and open PR.

What do you think?

[krisis]

@chshersh It would be awesome to have this feature in hit.
I have a question regarding how listing of issues would work in the presence of forks. Usually the upstream repository is where the issues are maintained, so hit issue should be listing issues from the upstream repository, right?

[chshersh]

@krisis We haven't designed this feature entirely yet. But I tend to agree that listing of all issues should be from the upstream repository by default. And since we're using github library, we can get the information about whether the library is a fork or not:

• https://github.com/phadej/github/blob/1eb7257055b693d17b68e3f454c574accc618cb0/src/GitHub/Data/Repos.hs#L39

Note, that even if forked projects can have their own issues as well (like the following library):

• https://github.com/phadej/postgresql-simple

But I guess a more typical workflow with forked libraries is when you're not a maintainer, but rather a contributor. And you want to list all issues from the original repo, not from the fork.

[krisis]

@chshersh, I agree with the points you make above. I hadn't thought through the different combinations of forks vs owned repositories and maintainer vs contributor when I made the comment earlier.

This is how I imagine the workflow for a contributor working on forked project to be,

1. Fork your favorite project on github.com
   e.g, kowainik/hit-on to krisis/hit-on

2. Clone the repo

hit clone hit-on

This should,

• Clone the repo from your fork (if available), else fail the command
• Set origin and upstream accordingly like e.g, upstream would be kowainik/hit-on and origin would be krisis/hit-on

3. List the issues (upstream) that you can pick and work on

hit issue 

4. If the contributor wishes to track personal development milestones using issues in their fork
   We could make it possible using a boolean flag like,

hit issue --local

Is this close to how you are thinking about this?