Question:
Is there a way to combine the advantages of GitHub's fine-grained PATs with the simplicity of git pull over HTTPS? If so, then how?
Background
GitHub has "classic" and "fine-grained" personal access tokens (PATs):

Go to Settings > Developer Settings to see these.
I have been using a classic PAT to run git pull commands over HTTPS, to pull the latest commits from GitHub:
git pull https://${token}@github.com/${owner}/${repo}.git
This works without prompting for a password (I keep the PAT's expiration period reasonably short).
I cannot just (naively) substitute a new fine-grained token for the classic token in my git pull command. It prompts me for a password. (It is treated as a user ID, I assume.)
Fine-grained PATs certainly work with the GitHub REST API. I can use the API to get a commit if I have the commit SHA. But that is quite low-level compared to git pull and I don't want to "reimplement a lot of Git functionality" (ref).
Fine-grained PATs are welcomed because of their ability to lock down access to specific repos and specific functions. But how (if at all) can they be used directly with git pull commands?
I am using Git v2.38.1 (the latest release, currently).
I used @bk2204's answer and took the following steps, to move from a "token-in-the-URL" approach (bad!) to a "credentials-in-a-store" approach (better!).
Using the newer GitHub fine-grained tokens for this worked without a problem.
I wanted to document the specific steps - here they are.
In GitHub:
Create a new PAT: Settings > Developer Settings > Fine-grained tokens.
Give this token access to one repository.
Grant one Repository permission: Contents (read-only).

This also automatically sets the Metadata (read-only) permission, as well.
On my server:
This is a headless Linux box. I do not have any 3rd party key stores integrated with Git (for example, no libsecret).
I chose to use the Git-provided store. Although this stores credentials in plaintext, it's no less secure (in my opinion) than SSH keys stored in .ssh. This is acceptable for my situation - and is far better than what I have been doing (placing a token directly in the URL of the pull command).
Specific one-time set-up commands:
git config --global credential.helper store
git config --global credential.useHttpPath true
That creates the following in my global .gitconfig file:
[credential]
helper = store
useHttpPath = true
Then, in my Git repo directory, I run a simple pull:
git pull https://github.com/${owner}/${repo}.git
As a one-time step, I have to manually provide my user ID and the PAT at the prompts.
These credentials are stored in a new (for me) .git-credentials file. The format of the credentials is:
https://<user ID>:<fine-grained PAT>@github.com/<owner>/<repo>.git
I can repeat this process for more repos, each with their own PAT, as needed.
When I execute subsequent git pull commands, the relevant URL-specific credentials from the store are used - no command line interaction is needed.
Using same format for git pull command as classic token
git pull https://${token}@github.com/${owner}/${repo}.git
It gives a three choices to me.
#1 First (Sign in with your browser): I can login by username and password
#2 Second (Sign in with a code) : I can login by 8 digits hex code
#3 Third (Token) : I can login by fine token (PAT)

The Fine token assigned all repository or specific repositories only. And assign detail permissions by PAT UI screen.
Here is detail information about Fine grained PAT.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With