Forge uses the Ghub package to access the APIs of supported Git forges. Ghub comes with a setup wizard that guides the user through the process of creating an API token for Github.com. When accessing a Github Enterprise instance, then some manual setup is required before the wizard can be used. Other forges don’t support creating tokens using the API at all. Before accessing such a forge you have to create a token using the respective web interface.
Please consult Ghub’s manual to learn more about token creation. See (ghub)Getting Started in particular.
Ghub does not associate a given local repository with a repository on
a forge. The Forge package itself takes care of this. In doing so it
ignores the Git variable
ghub.host and other
FORGE.host variables used
by Ghub. (But
github.user and other variables used to specify the
user are honored). Forge associates the local repository with a forge
repository by first determining which remote is associated with the
upstream repository and then looking that up in
If only one remote exists, then Forge uses that unconditionally. If several remotes exist, then a remote may be selected based on its name.
The convention is to name the upstream remote
origin. If you follow
this convention, then you have to do nothing else and the remote by
that name is automatically used, provided it exists and regardless of
whether other remotes exist. If it does not exist, then no other
remotes are tried.
If you do not follow the naming convention, then you have to inform
Forge about that by setting the Git variable
forge.remote to the name
that you instead use for upstream remotes. If this variable is set,
then Forge uses the remote by that name, if it exists, the same way
it may have used
origin if the the variable were undefined. I.e. it
does not fall through to try
origin if no remote by your chosen name
Once the upstream remote has been determined, Forge looks it up in
forge-alist, using the host part of the url as the key. For example
the key for