Troubleshooting of GIT - Revision history

Planetoid: /* Git Push Failed: Invalid username or token (GitHub No Longer Supports Password Authentication) */

2026-08-07T06:59:51Z

Git Push Failed: Invalid username or token (GitHub No Longer Supports Password Authentication)

← Older revision		Revision as of 14:59, 7 August 2026
Line 10:		Line 10:
	<pre>		<pre>
	remote: Invalid username or token. Password authentication is not supported for Git operations.		remote: Invalid username or token. Password authentication is not supported for Git operations.
	fatal: Authentication failed for 'https://github.com/~~team_name~~/~~repo_name~~/'		fatal: Authentication failed for 'https://github.com/your-org/your-repo/'

	In a case you entered incorrect password, please		In a case you entered incorrect password, please

Planetoid: /* Troubleshooting of GIT */

2026-08-07T06:59:21Z

Troubleshooting of GIT

Show changes

Planetoid: /* Git Shows Files as Modified After chmod — File Mode Changes */

2026-08-07T06:56:45Z

Git Shows Files as Modified After chmod — File Mode Changes

← Older revision		Revision as of 14:56, 7 August 2026
Line 379:		Line 379:

	so Git always uses the correct SSH key.		so Git always uses the correct SSH key.

			=== Git Push Failed: Invalid username or token (GitHub No Longer Supports Password Authentication) ===

			'''Problem'''

			Running <code>git push</code> produces the following error:

			<pre>
			remote: Invalid username or token. Password authentication is not supported for Git operations.
			fatal: Authentication failed for 'https://github.com/team_name/repo_name/'

			In a case you entered incorrect password, please
			update it in Keychain Access application.
			</pre>

			'''Diagnosis'''

			First check the current login status of the GitHub CLI:

			<pre>
			gh auth status
			</pre>

			If the token has expired, a message similar to the following will appear:

			<pre>
			github.com
			X Failed to log in to github.com account UserName (keyring)
			* Active account: true
			* The token in keyring is invalid.
			* To re-authenticate, run: gh auth login -h github.com
			* To forget about this account, run: gh auth logout -h github.com -u UserName
			</pre>

			You can also directly query the GitHub credentials stored in the macOS Keychain:

			<pre>
			security find-internet-password -s github.com
			</pre>

			'''Cause'''

			This error is typically caused by one of the following:

			* An old GitHub account password (rather than a token) is stored in the macOS Keychain, and Git's attempt to authenticate with that password fails.
			* The Personal Access Token in the <code>gh</code> keyring has expired, been revoked, or had its permissions changed.
			* A token or SSH key was never set up, so Git is still falling back to the legacy password authentication flow.

			'''Solution'''

			'''Re-authenticate the GitHub CLI'''

			<pre>
			gh auth login -h github.com
			</pre>

			Select the following options in order:

			* What is your preferred protocol for Git operations on this host? → <code>HTTPS</code> (matches the existing remote protocol)
			* How would you like to authenticate GitHub CLI? → <code>Login with a web browser</code>

			A one-time code will be displayed. Copy it and press Enter; a browser window will open the GitHub device authorization page to complete the login:

			<pre>
			! First copy your one-time code: XXXX-XXXX
			Press Enter to open https://github.com/login/device in your browser...

			✓ Authentication complete.
			* gh config set -h github.com git_protocol https
			✓ Configured git protocol
			✓ Logged in as UserName
			</pre>

	=== Git Shows Files as Modified After chmod — File Mode Changes ===		=== Git Shows Files as Modified After chmod — File Mode Changes ===

Planetoid: /* Git Shows Files as Modified After chmod — File Mode Changes */

2026-07-13T06:54:42Z

Git Shows Files as Modified After chmod — File Mode Changes

← Older revision		Revision as of 14:54, 13 July 2026
Line 429:		Line 429:
	If the output contains only <code>old mode</code> and <code>new mode</code>, without added or removed content lines, the change is caused by the executable bit rather than file contents.		If the output contains only <code>old mode</code> and <code>new mode</code>, without added or removed content lines, the change is caused by the executable bit rather than file contents.

	Check the current repository setting with:		Check the current repository setting with: <ref>[https://git-scm.com/docs/git-config?utm_source=chatgpt.com Git - git-config Documentation]</ref>

	<pre>		<pre>
Line 547:		Line 547:

	{{exclaim}} Notice: Setting <code>core.fileMode=false</code> does not change the actual operating-system permissions and does not rewrite previously committed file modes. It only tells Git not to treat executable-bit differences in the working tree as modifications. Use a repository-level setting unless the same problem consistently affects all repositories on the machine.		{{exclaim}} Notice: Setting <code>core.fileMode=false</code> does not change the actual operating-system permissions and does not rewrite previously committed file modes. It only tells Git not to treat executable-bit differences in the working tree as modifications. Use a repository-level setting unless the same problem consistently affects all repositories on the machine.


	=== Git Submodule Pull Failed: unable to create file — File exists ===		=== Git Submodule Pull Failed: unable to create file — File exists ===

Planetoid: /* Git Submodule Pull Failed: unable to create file — File exists */

2026-07-13T06:52:54Z

Git Submodule Pull Failed: unable to create file — File exists

Show changes

Planetoid: /* SSH Authentication Failed: Permission denied (publickey) */

2026-07-08T04:21:36Z

SSH Authentication Failed: Permission denied (publickey)

Show changes

Planetoid: /* SSH Authentication Failed: Permission denied (publickey) */

2026-06-17T08:04:55Z

SSH Authentication Failed: Permission denied (publickey)

← Older revision		Revision as of 16:04, 17 June 2026
Line 60:		Line 60:

	{{exclaim}} Notice: `-o IdentitiesOnly=yes` prevents SSH from trying other keys loaded in the agent, which can cause unexpected auth failures.		{{exclaim}} Notice: `-o IdentitiesOnly=yes` prevents SSH from trying other keys loaded in the agent, which can cause unexpected auth failures.


			=== Git Submodule Pull Failed: unable to create file — File exists ===

			'''Error Message'''

			After pulling in GitHub Desktop, met the error message

			<pre>
			Fetching submodule lib
			error: unable to create file feeds/example.php: File exists
			Updating xxxxxxxx..xxxxxxxx
			</pre>

			'''Cause'''

			When Git tries to update the submodule to a newer commit, it finds a local untracked file with the same name, blocking the checkout. A mid-pull failure leaves the submodule in an inconsistent state and causes a large number of unexpected unstaged changes to appear in GitHub Desktop.

			'''Solution'''

			Run the following command in the project root directory to force re-sync the submodule:

			<pre>
			git submodule update --init --recursive --force
			</pre>

			If it still fails, manually remove the conflicting file and retry:

			<pre>
			rm lib/feeds/example.php
			git submodule update --init --recursive
			</pre>

			Enter the submodule directory and verify the status is clean:

			<pre>
			cd lib
			git status
			</pre>

			The expected output should be:

			<pre>
			HEAD detached from xxxxxxxx
			nothing to commit, working tree clean
			</pre>

			`nothing to commit, working tree clean` confirms the submodule has been successfully synced — return to GitHub Desktop and continue as normal. `HEAD detached` is the expected state for a submodule and does not require any action.

			{{exclaim}} Notice: The large number of unstaged changes appearing in GitHub Desktop after a failed Pull will typically return to normal once the submodule is fixed. If unexpected changes still remain, run <code>git submodule foreach git checkout .</code> to revert all modifications inside every submodule.

	== Further Reading ==		== Further Reading ==

Planetoid: Created page with " == Troubleshooting of GIT == === Restoring deleted files in Git === Restoring deleted files in Git === SSH Authentication Failed: Permission denied (publickey) === '''Error Message''' After keyin the command

git clone git@github.com:your-org/your-repo.git /opt/your-app

, met the error message

 Cloning into '/opt/your-app'... git@github.com: Permission denied (publickey). fatal: Could not read from remote repository.  Please make sure you have the..."

2026-06-04T06:39:32Z

Created page with " == Troubleshooting of GIT == === Restoring deleted files in Git === Restoring deleted files in Git === SSH Authentication Failed: Permission denied (publickey) === '''Error Message''' After keyin the command <pre>git clone git@github.com:your-org/your-repo.git /opt/your-app</pre>, met the error message <pre> Cloning into '/opt/your-app'... git@github.com: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the..."

New page

== Troubleshooting of GIT ==

=== Restoring deleted files in Git ===
[[Restoring deleted files in Git]]

=== SSH Authentication Failed: Permission denied (publickey) ===

'''Error Message'''

After keyin the command <pre>git clone git@github.com:your-org/your-repo.git /opt/your-app</pre>, met the error message

<pre>
Cloning into '/opt/your-app'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.
</pre>

'''Cause'''

This error occurs when Git cannot authenticate with GitHub over SSH. This typically means the SSH key on your machine is either missing, not registered with your GitHub account, or not being picked up by the SSH agent.

'''Solutions'''

'''Option 1 — Configure your SSH config file'''

Add an entry to `~/.ssh/config` so Git automatically uses the correct key:

<pre>
Host github.com
HostName github.com
User git
IdentityFile /path/to/.ssh/your_key_name
</pre>

'''Option 2 — Pass the SSH key inline'''

1. Before running `git clone`, test whether the specified SSH key can successfully authenticate with GitHub:

<pre>
ssh -T -i /path/to/.ssh/your_key_name git@github.com
</pre>

If the key is configured correctly, you should see:

<pre>
Hi your-org/your-app! You've successfully authenticated, but GitHub does not provide shell access.
</pre>

`successfully authenticated` confirms the key is correctly linked to your GitHub account and you're good to proceed with `git clone`. The message `GitHub does not provide shell access` is expected — SSH is used for Git operations only, not for interactive shell login.

2. Override the SSH command directly when cloning:

<pre>
sudo GIT_SSH_COMMAND='ssh -i /path/to/.ssh/your_key_name -o IdentitiesOnly=yes' \
git clone git@github.com:your-org/your-repo.git /opt/your-app
</pre>

{{exclaim}} Notice: `-o IdentitiesOnly=yes` prevents SSH from trying other keys loaded in the agent, which can cause unexpected auth failures.

== Further Reading ==

* [https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent Generating a new SSH key and adding it to the ssh-agent - GitHub Docs]
* [https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account Adding a new SSH key to your GitHub account - GitHub Docs]
* [https://docs.github.com/en/authentication/connecting-to-github-with-ssh/testing-your-ssh-connection Testing your SSH connection - GitHub Docs]
* [https://linux.die.net/man/5/ssh_config ssh_config(5): OpenSSH SSH client config files - Linux man page]
* [https://docs.github.com/en/authentication/troubleshooting-ssh Troubleshooting SSH - GitHub Docs]

[[Category: Git]]
[[Category: Revised with LLMs]]