Oh My GitHub 1.0 is out!

https://en.liujiacai.net/2022/11/26/oh-my-github-1-0/

Magithub author here. Neat package! I think it would benefit your README to compare your package to others in the space (particularly Magit Forge) that your readers would already be familiar with. Beyond that, I would strongly encourage you to use the standard authentication storage mechanisms in emacs (authinfo) to keep your users’ secrets secure. In the context of a long-running process like emacs, environment variables and normal defvars are very…public.

To add a pointer to said standard mechanisms, there's apparently an info manual: [(info "(auth) Top")](https://www.gnu.org/software/emacs/manual/html_node/auth/index.html)

Thanks for suggestion. I haven't used Forge, so couldn't provide much information now. I will add oh-my-github's design principle in readme, to let users decide whether it fit their requirements. > I would strongly encourage you to use the standard authentication storage mechanisms in emacs (authinfo) to keep your users’ secrets secure https://github.com/jiacai2050/oh-my-github/issues/51

With this incredible knowledge gathered here I am just gonna use this thread to ask: When I did a fork of a repo on GitHub, then cloned it into my computer and did some edits, how do I create a PR from my fork onto the original repository? All o can do is making PRs between branches of my own repo.

Can you clarify which package you’re using? If you’re using Forge, I suspect you need to ensure you have both repositories added as remotes. If you’re using Magithub, pretty sure it’s the same problem, but you should consider moving to Forge (I personally find value in focusing community effort on one solution). If it’s OP’s package, you should ping OP :-)

Magit forge. Thanks I will give that a try. Although I think I tried that already. But I’m not sure, I’m a bit confused tbh

Cross-repository pull requests is quietly same with PR in same repo, just set `head` with a user like this: `username:branch` if you want to try oh-my-github. ``` #+TITLE: Awesome title #+TARGET-REPO: upstream/foo #+TARGET-BRANCH: main #+SOURCE-HEAD: my:main #+DRAFT: false ```

The problem probably is that your fork is named `origin` (this is the default name used by `git clone`) and the upstream is named `their-name`. Forge doesn't *know* which remote corresponds to the upstream repository, so it uses heuristics, one of them being "it's `origin`". Many people clone their remote and then add the upstream remote using `git remote add --name upstream`, which IMO is wrong(tm). But because so many people do it, I have chosen to prefer `upstream` over `origin`. I *recommend* that you always start by cloning the upstream (using the default name `origin`) and then add your *fork* (using whatever name you fancy (just not `upstream`)). For local repositories that you have already cloned from your fork, I recommend you rename the remote from `origin` to something else, before adding the upstream as `origin`, and changing the upstream *branch* of `master` (and maybe other branches) from `my-fork/master` to `origin/master`. That's more work, which is why I recommend, that, going forward, you always begin with cloning the upstream.

> I haven't used Forge, so couldn't provide much information now. Forge is essentially *the* tool for doing such things. You will necessarily reinvent many wheels by writing your own. That's fine, of course, but I'd recommend taking a serious look at Forge first, and considering contributing to it instead.

According to Forge homepage, it seems it require Magit to work. oh-my-github's Emacs interface require nothing but Emacs(28+), so this maybe its one advantage. All that said, oh-my-github is not only designed for Emacs, it's designed as a generic framework for working with GitHub API. oh-my-github's core is written in C, so other language may use it as a library via FFI, I plan to improve CLI interface in future. Hope this explain what oh-my-github's design principle is, and why it exists besides X/Y/Z.

Thanks for the additional explanation. > All that said, oh-my-github is not only designed for Emacs, it's designed as a generic framework for working with GitHub API. FYI, Forge is designed as a generic framework for working with any GitHub-like site, including GitLab, etc. It's also implemented in a high-level language, i.e. Elisp. That's why I suggested looking into its implementation.

Hey, I just noticed you are the dev of magit. Thank you for your work! This thing is really one of the biggest reasons to stick to emacs. Interactive rebasing in magit is no much better than in command line git, I forgot how to do it there. :D / nevermind the following, I cloned the origin again and added my fork as remote. No it works like a charm. I changing the config file of git manually is a no-no if you don't know what you're doing. I renamed the remote from origin to myfork and added the upstream as origin. I changed upstream branch the branch of master to origin/master. I can create a PR now, in the sense of I can choose my local branch as the source branch and origin/master as the target. However, when I do C-c C-c on that PR it only responds with ``` Cannot determine forge repository. No url configured for ".". See https://magit.vc/manual/forge/Repository-Detection.html. ``` Clearly I set something wrong but I dont know whats missing. I think it should try setting the forge.remote variable with the url of origin, shouldn't it? This is the beginning of my git config for that repo. ``` [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "myfork"] url = git@github.com:Schievel1/gentoo.git fetch = +refs/heads/*:refs/remotes/origin/* gh-resolved = gentoo/gentoo fetch = +refs/pull/*/head:refs/pullreqs/* [remote "origin"] url = git@github.com:gentoo/gentoo.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] pushRemote = origin remote = origin merge = refs/heads/master [branch "gkrellshoot-clang16"] remote = myfork merge = refs/heads/gkrellshoot-clang16 ```

I use "old reddit" where code blocks work differently. Please indent every line with four spaces. Make sure you push the feature branch to your fork before trying to open a pull-request and then select `myfork/feature` as the source.

Thanks for your help, but I recloned upstream and added my fork as another remote instead. Forge could really use some documentation in the form of a step by step guide. Is there anything out there I don’t know about? Otherwise I would write one after a few weiß of usage

> Forge could really use some documentation in the form of a step by step guide. Many users are having difficulties getting started, so obviously there is something inherently difficult about configuring Forge. Unfortunately I don't know how I can improve any further. The split between `ghub` and `forge` is certainly a problem, but it's too late to change that. Also both packages support multiple forge types and forge instances, which comes with some unavoidable complexity. I have tried countering these difficulties by writing a (okay two) very detailed getting started guide, which you can start reading at https://magit.vc/manual/forge/Getting-Started.html. It begins with: > Initial setup turned out to more challenging for many users than I had hoped. I am trying to counter that by providing detailed instructions that cover not just the happy path but also many of the issues users have ran into in the past. The recommended reading is longer than one might wish, but skipping it does not necessarily save time. To required reading is long and quite detailed. It undeniably is too long and detailed for every user, but the problem is that one users "this is obvious and you didn't have to describe that in so much detail" is someone else's "this is where I got wrong". Alternative guides that only describe the happy path do exist. One is mentioned on the wiki: https://practical.li/spacemacs/source-control/forge-configuration.html.

Thanks. The one in the wiki was what I had on my mind. I haven’t found it myself, so I will spread the word a bit