Tuesday, 21 September 2021

Today I Learned - more about Git config

Whilst trying to create a container image from a project on GitHub, I hit an issue with the cloning process of the GH repository ...

Specifically, the repo contains a submodule which, in my simple brain, is where one project/repo includes the content of another project/repo as an internal dependency.

I was cloning the original project using it's HTTPS URL rather than, say, via a SSH key pair.

Which is normally fine ...

However, I needed to provide a GitHub Personal Access Token for the clone, as the repo is private/protected.

This works perfectly: -

git clone --recurse-submodules 


Well, to a point .... the repo clone worked BUT the submodule failed to clone, because it, too, wanted a set of credentials ...

Thus I saw: -

Submodule 'submodule-dependency' (https://github.com/organization/submodule-dependency.git) registered for path 'submodule-dependency'
Cloning into '/tmp/project-repo/submodule-dependency'...
Username for 'https://github.com': ^Cwarning: Clone succeeded, but checkout failed.

which was a PITA.

There is, however, a solution AND a happy ending ...

I'd previously used the insteadOf property within my Git config: -

git config --global url."git@github.com:".insteadOf "https://github.com"

when I wanted to ensure that git clone used my SSH private key for authentication to private/protected repositories ...

There's an equivalent in the world of cloning submodules via HTTPS ...

git config --global url."https://x-access-token:${ACCESS_TOKEN}@github.com".insteadOf https://github.com

which solves the problem nicely.

One thing to note, however, this does mean that the value of the $ACCESS_TOKEN variable is then persisted to the global Git configuration, and can thus be seen via: -

git config --global --list

There is, however, a solution to this: -

git config --global --unset url."https://x-access-token:${ACCESS_TOKEN}@github.com".insteadOf https://github.com

git config --global --unset credential.helper

Easy when you know, NOW ?

No comments:

Yay, VMware Fusion and macOS Big Sur - no longer "NAT good friends" - forgive the double negative and the terrible pun ...

After macOS 11 Big Sur was released in 2020, VMware updated their Fusion product to v12 and, sadly, managed to break Network Address Trans...