How do you guys use forge with magit and github?

curious on the specific workflows to fork a project on github all the way to contributing a pull request. The manual describes a lot of options, some steps can take place on github vs others on emacs - how do you guys normally go about it? 1. forking the repo - this you do on github then save the links to the original project and your fork? 2. clone your fork (or original?) regular magit can do the clone, or commandline, or forge? 3. add the original project remote calling it upstream if you cloned your own copy (or perhaps adding your fork as another remote if you cloned the original?) 4. hereafter everything can be done in forge or do any of you still switch to browser for some things?

Watching this one for myself.

I don't want to claim that anything I do is optimal; I'm just describing what I do. I fork on github, clone my fork to a local repo from the command line, push/pull to/from my fork only using Magit or the command line at my whim. So my local git repo usually knows nothing of the true upstream/origin -- my fork is "origin" -- it is all to/from my fork. I find that dropping to the command line to do infrequently performed or delicate git operations to be better. The steps you perform are more clear, and are more likely to match online guides, etc. Magit is a big win when doing the "usual" things, especially committing. If I planned to maintain a long lived feature branch I might bother to teach git about the original origin, maybe calling it "upstream", so I can pull from it and merge or rebase. There is also [https://github.com/magit/forge](https://github.com/magit/forge), which I haven't looked at. Instead, I do all the proprietary github things through their proprietary website. I find this to be more honest -- I know when I am selling my soul.

- forking the repo: I fork from forge, using `forge-fork`. - clone your fork (or original?) regular magit can do the clone, or commandline, or forge? This question isn't very clear to me. I clone the original repo using `magit-clone` or from the command line. Further management is done using forge. - add the original project remote calling it upstream if you cloned your own copy (or perhaps adding your fork as another remote if you cloned the original?) I usually name the original project remote as `origin`. My fork is `copy` or something else. This works well with what forge expects by default. - hereafter everything can be done in forge or do any of you still switch to browser for some things? I use the browser for viewing topics in large repos that I don't own, and for reviewing PRs on my repos. All other actions (viewing or creating new topics, notifications, replying to topics, trying out and merging PRs etc) are through forge. EDIT: Here's a typical process. 1. `magit-clone` or `git clone` a repo. The remote is named `origin`. 2. Add it to forge's database, pulling individual or all topics (`N a`) 3. Contribute to or create issues with forge. (`N f t`, then `C-c C-r` or `C-c C-e` to reply.) 3. Fork the repo to my account with `forge-fork`. My remote is named `copy`, or something else. 4. Work on the local repo as usual, push to `copy`. 5. Create a PR using forge.

This is basically my process as well

Somehow I had not appreciated "add to database", which is the key for the full workflow you describe. Thanks. If you don't mind my asking, do you have a similar all-emacs solution for a common scenario I find myself in: after playing around with some code, I decide it deserves its own remote repository. I.e. can you create a brand new remote repository with forge *where there was none before*?

that is quite the forge power use i would have thought topic creation hard with templates behind them to like select OS version and checkmark things but the above sounds wonderfully emacs centric

> topic creation hard with templates behind them to like select OS version and checkmark things Forge appears to handle these things, it prepopulates the topic editing buffer with the template.