No such file or directory git bash ошибка

Александр, здравствуйте!
Подскажите, пожалуйста, мне не удается склонировать проект.
Постоянно выходит ошибка: No such file or directory.
Ключи SSH я сформировала, прописала на GitHub, сохранила.
Далее, при вводе команды: git@github.com: имя проекта
выходит сообщение: bash: git@github.com: имя проекта.git: No such file or directory
На всех возможных ресурсах ищу ответ, исправить не удается.
Как исправить ошибку?

fatal: could not read Username for 'https://github.com': No such file or directory

This question is related to
git
github
git-pull
git-bash

I faced the exact same problem. This problem occurred when I cloned using HTTPS URL and then tried to push the changes using Git Bash on Windows using:

git clone https://github.com/{username}/{repo}.git

However, when I used SSH URL to clone, this problem didn’t occur:

git clone [email protected]:{username}/{repo}.git

For me nothing worked from suggested above, I use git pull from jenkins shell script and apparently it takes wrong user name. I spent ages before I found a way to fix it without switching to SSH.

In your the user’s folder create .gitconfig file (if you don’t have it already) and put your credentials in following format: https://user:[email protected], more info. After your .gitconfig file link to those credentials, in my case it was:

[credential]
helper = store --file /Users/admin/.git-credentials

Now git will always use those credentials no matter what. I hope it will help someone, like it helped me.

Note that if you are getting this error instead:

fatal: could not read Username for 'https://github.com': No error

Then you need to update your Git to version 2.16 or later.

I found my answer here:

edit ~/.gitconfig and add the following:

[url "[email protected]:"]
 insteadOf = https://github.com/

Although it solves a different problem, the error code is the same…

If you want to continue use https instead ssh, and avoid type into your username and password for security reason.

You can also try Github OAuth token, then you can do
git config remote.origin.url 'https://{token}@github.com/{username}/{project}.git'
or
git remote add origin 'https://{token}@github.com/{username}/{project}.git'

This works for me!

This error can also happen when trying to clone an invalid HTTP URL. For example, this is the error I got when trying to clone a GitHub URL that was a few characters off:

$ git clone -v http://github.com/username/repo-name.git
Cloning into 'repo-name'...
Username for 'https://github.com': 
Password for 'https://github.com': 
remote: Repository not found.
fatal: Authentication failed for 'https://github.com/username/repo-name.git/'

It actually happened inside Emacs, though, so the error in Emacs looked like this:

fatal: could not read Username for ’https://github.com’: No such device or address

So instead of a helpful error saying that there was no such repo at that URL, it gave me that, sending me on a wild goose chase until I finally realized that the URL was incorrect.

This is with git version 2.7.4.

I’m posting this here because it happened to me a month ago and again just now, sending me on the same wild goose chase again. >:(

Short Answer:

git init
git add README.md
git commit -m "first commit"


git remote add origin https://github.com/{USER_NAME}/{REPOSITORY_NAME}.git
git push --set-upstream origin master

Ignore first three lines if it’s not a new repository.

Longer description:

Just had the same problem, as non of the above answers helped me, I have decided to post this solution that worked for me.

Few Notes:

• The SSH key was generated
• SSH key was added to github, still had this error.
• I’ve made a new repository on GitHub for this project and followed the steps described

As the command line tool I used GitShell (for Windows, I use Terminal.app on Mac).
GitShell is official GitHub tool, can be downloaded from https://windows.github.com/

Hope this helps to anyone who has the same problem.

For those getting this error in a Jenkins pipeline, it can be fixed by using an SSH Agent plugin. Then wrap your git commands in something like this:

sshagent(['my-ssh-key']) {
    git remote set-url origin [email protected]:username/reponame.git
    sh 'git push origin branch_name'
}

TL;DR: check if you can read/write to /dev/tty. If no and you have used su to open the shell, check if you have used it correctly.

I was facing the same problem but on Linux and I have found the issue. I don’t have my credentials stored so I always input them on prompt:

Username for 'https://github.com': foo
Password for 'https://[email protected]': 

The way how git handles http(s) connections is using /usr/lib/git-core/git-remote-https
you can see strace here:

stat("/usr/lib/git-core/git-remote-https", {st_mode=S_IFREG|0755, st_size=1366784, ...}) = 0
pipe([9, 10])                           = 0
rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f65398bb350) = 18177
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(10)                               = 0
read(9, "", 8)                          = 0
close(9)                                = 0
close(5)                                = 0
close(8)                                = 0
dup(7)                                  = 5
fcntl(5, F_GETFL)                       = 0 (flags O_RDONLY)
write(6, "capabilities\n", 13)          = 13
fstat(5, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
read(5, "fetch\noption\npush\ncheck-connecti"..., 4096) = 38
write(6, "option progress true\n", 21)  = 21
read(5, "ok\n", 4096)                   = 3
write(6, "option verbosity 1\n", 19)    = 19
read(5, "ok\n", 4096)                   = 3
stat(".git/packed-refs", {st_mode=S_IFREG|0664, st_size=675, ...}) = 0
lstat(".git/objects/10/52401742a2e9a3e8bf068b115c3818180bf19e", {st_mode=S_IFREG|0444, st_size=179, ...}) = 0
lstat(".git/objects/4e/35fa16cf8f2676600f56e9ba78cf730adc706e", {st_mode=S_IFREG|0444, st_size=178, ...}) = 0
dup(7)                                  = 8
fcntl(8, F_GETFL)                       = 0 (flags O_RDONLY)
close(8)                                = 0
write(6, "list for-push\n", 14)         = 14
read(5, fatal: could not read Username for 'https://github.com': No such device or address
"", 4096)                       = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=18177, si_uid=1000, si_status=128, si_utime=6, si_stime=2} ---
exit_group(128)                         = ?
+++ exited with 128 +++

So I tried to call it directly:

echo "list for-push" | strace /usr/lib/git-core/git-remote-https my

and the result:

poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 1 ([{fd=3, revents=POLLIN|POLLRDNORM}])
recvfrom(3, "\27\3\3\1\32", 5, 0, NULL, NULL) = 5
recvfrom(3, "\307|4Q\21\306\334\244o\237-\230\255\336\25\215D\257\227\274\r\330\314U\5\17\217T\274\262M\223"..., 282, 0, NULL, NULL) = 282
openat(AT_FDCWD, "/dev/tty", O_RDONLY)  = -1 ENXIO (No such device or address)
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=2995, ...}) = 0
read(4, "# Locale name alias data base.\n#"..., 4096) = 2995
read(4, "", 4096)                       = 0
close(4)                                = 0
openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "fatal: could not read Username f"..., 83fatal: could not read Username for 'https://github.com': No such device or address
) = 83
exit_group(128)                         = ?
+++ exited with 128 +++

And here it came to me:

openat(AT_FDCWD, "/dev/tty", O_RDONLY)  = -1 ENXIO (No such device or address)
...
write(2, "fatal: could not read Username f"..., 83fatal: could not read Username for 'https://github.com': No such device or address
) = 83

git-remote-https tries to read credentials via /dev/tty so I tested if it works:

$ echo ahoj > /dev/tty
bash: /dev/tty: No such device or address

But in another terminal:

# echo ahoj > /dev/tty
ahoj

I knew I switched to this user using su so I exited the shell to see how and found out I used command su danman - so I tested it again:

~# su danman -
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
/root$ echo ahoj > /dev/tty
bash: /dev/tty: No such device or address

I probably ignored the message and continued working but this was the reason.
When I switched using the correct su - danman everything worked fine:

~# su - danman
danman@speedy:~$ echo ahoj > /dev/tty
ahoj

After this, git started working correctly

Replace your remote url like this:

git remote set-url origin https://<username>@github.com/<username>/<repo>.git

This is an issue with your stored credentials in the system credential cache. You probably have the config variable ‘credential.helper’ set to either wincred or winstore and it is failing to clear it. If you start the Control Panel and launch the Credential Manager applet then look for items in the generic credentials section labelled «git:https://github.com». If you delete these, then the will be recreated next time but the credential helper utility will ask you for your new credentials.

Double check the repository URL, Github will prompt you to login if the repo doesn’t exist.

I’m guessing this is probably to check if it’s a private repo you have access to. Possibly to make it harder to enumerate private repos. But this is all conjecture. /shrug

Earlier when I wasn’t granted permission to access the repo, I had also added the SSH pubkey to gitlab. At the point I could access the repo and run go mod vendor, the same problem as your happens. (maybe because of cache)

go mod vendor

go: errors parsing go.mod:
/Users/macos/Documents/sample/go.mod:22: git ls-remote -q https://git.aaa.team/core/some_repo.git in /Users/macos/go/pkg/mod/cache/vcs/a94d20a18fd56245f5d0f9f1601688930cad7046e55dd453b82e959b12d78369: exit status 128:
    fatal: could not read Username for 'https://git.aaa.team': terminal prompts disabled

After a while trying, I decide to remove the SSH key and terminal prompts filling in username and password. Everything is fine then!

Try using a normal Windows shell such as CMD.

trying the CreativeMagic solution, the credential problem is confirmed:

prompt>>>Username for ‘https://github.com’

So, I changed my origin url with

git remote set-url --add origin http://github.com/user/repo

and

git push --set-upstream origin master

What worked for me is to change the access of the Git repository from private to public.

История просмотров

One of the fun things about working with Git on Windows is that you’re often
at the mercy of the filesystem underneath you, and this crops up in some
entertaining ways:

• even though NTFS supports running as a case sensitive filesystem, the Win32
  subsystem does not support filenames that differ by case sensitivty only
• some characters are not permitted by Win32 subsystem APIs — and I refer back to
  this link
  regularly to remind myself of this.

Even in the age of running Linux on Windows,
these compatibility issues are not going away any time soon, and taking a
repository and running it on Windows can be problematic, so the rest of this
post is about repairing these repositories so they are not tied to a particular
filesystem.

Please note

• All of these operations are being run inside Git Bash that ships with Git
  for Windows — if you are trying to perform the same actions in a different
  shell they’re likely to fail.
• These instructions are tailored to one repository. You’ll need to adapt
  these based on the problem file paths you encounter in your situation.
• This repository has been fixed, so you probably won’t be able to
  replicate the same behaviour by running the exact same commands either.

The Scene — A Failing Clone

You might have stumbled upon an error like this when cloning down someone else’s
repository:

$ git clone https://github.com/MCanterel/Dual_Brains
Cloning into 'Dual_Brains'...
remote: Counting objects: 12023, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 12023 (delta 9), reused 14 (delta 4), pack-reused 12000
Receiving objects: 100% (12023/12023), 56.77 MiB | 6.63 MiB/s, done.
Resolving deltas: 100% (5891/5891), done.
error: unable to create file test-files/SavedDataOpenBCI-RAW-aaron+eva.txt: No such file or directory
error: unable to create file test-files/SavedDataOpenBCI-RAW-friday_test.txt: No such file or directory
Checking out files: 100% (9136/9136), done.
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'

So here is where Git is actually falling over:

error: unable to create file test-files/SavedDataOpenBCI-RAW-aaron+eva.txt: No such file or directory
error: unable to create file test-files/SavedDataOpenBCI-RAW-friday_test.txt: No such file or directory

Did you read the link
above about valid file path characters? I’ll quote the relevant part here:

Use any character in the current code page for a name, including Unicode characters and characters in the extended character set (128–255), except for the following:

• The following reserved characters:

  • < (less than)

  • (greater than)

  • : (colon)
  • » (double quote)
  • / (forward slash)
  • (backslash)
  • | (vertical bar or pipe)
  • ? (question mark)
  • • (asterisk)

• …

So we can’t use as a path in Windows, but we have a repository that has some
existing content using this character. That’s what we need to fix here.

At this point you could look inside the newly created repository on disk and
try to salvage things. I wouldn’t recommend this approach because of this error
message further down.

fatal: unable to checkout working tree

The working tree is the files on disk associated with the current branch (either
the default branch or whatever branch you wanted to initially checkout). And
with that in an unknown state, there is only pain ahead. Let’s try a different
way.

Part 1 — Fix The Problem Checkout

Because git clone fails I used this set of commands to emulate a clone
operation:

$ git init test-repo
$ cd test-repo
$ git remote add origin https://github.com/MCanterel/Dual_Brains -f

This gets us to a usable repository state, but these problem files still need
addressing:

$ git checkout origin/master -f
error: unable to create file test-files/SavedDataOpenBCI-RAW-aaron+eva.txt: No such file or directory
error: unable to create file test-files/SavedDataOpenBCI-RAW-friday_test.txt: No such file or directory
Checking out files: 100% (9136/9136), done.
Note: checking out 'origin/master'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 0cbfb99 Merge remote-tracking branch 'refs/remotes/upstream/master'

I’m going to just remove those so I have something to work with:

$ git checkout -b fix-path-issue-with-invalid-files
Switched to a new branch 'fix-path-issue-with-invalid-files'
D       "test-files/SavedData\OpenBCI-RAW-aaron+eva.txt"
D       "test-files/SavedData\OpenBCI-RAW-friday_test.txt"

$ git status
On branch fix-path-issue-with-invalid-files
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    "test-files/SavedData\OpenBCI-RAW-aaron+eva.txt"
        deleted:    "test-files/SavedData\OpenBCI-RAW-friday_test.txt"

no changes added to commit (use "git add" and/or "git commit -a")

$ git add .

$ git status
On branch fix-path-issue-with-invalid-files
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        deleted:    "test-files/SavedData\OpenBCI-RAW-aaron+eva.txt"
        deleted:    "test-files/SavedData\OpenBCI-RAW-friday_test.txt"

$ git commit -m "removed files with invalid paths"
[fix-path-issue-with-invalid-files 726d35a] removed files with invalid paths
 2 files changed, 131880 deletions(-)
 delete mode 100644 "test-files/SavedData\OpenBCI-RAW-aaron+eva.txt"
 delete mode 100644 "test-files/SavedData\OpenBCI-RAW-friday_test.txt"

Now we have no problems checking out this branch, but we did this by removing
the problem paths from the repository. If we want to be able to access those
files in the repository we have more work to do.

Part 2 — Put The Files Back

Git keeps a history of all the file contents for all commits in it’s .git
folder, and we can explore this using various Git plumbing commands.

We can use git ls-tree to read the tree contents of a given hash and
find the original contents of the files we just removed:

$ git ls-tree origin/master
100644 blob 4fda0922d502719782c70810a6d5ddb1c9bdd14d    .gitignore
040000 tree b39c2cabf1b81dba6e7b625ffa2d9e4535e7421f    Dual_Brains_Visualization
100644 blob fa4410c60ac7d6becebdbe43f5560976ae1d207b    README.md
040000 tree 8974c3cb0ae7f8bc05fc891cf481d58235ae5c83    aaron_test_data
040000 tree 68d65ff67f213859f124ed492428eebdb7a5d1ec    drafts
040000 tree 0ca5bae4b0173c9b2f47893136a6d0b299006378    images
040000 tree 7fe38978bb6d446ee4ac3d68a2a3ff006685c8ed    python
100644 blob ca9d99d426f059fdf0c377552d196a22ae2ff47a    requirements.txt
040000 tree e2a3b7648b57746e68ced4f881f193df05a2341f    test-files

Git stores each commit as a tree, and a tree can contain blobs (the file
contents) or other trees. Each entry in a tree also needs a mode (for representing
permissions) and a path. If you squint at this, it’s not unlike a filesystem
representation as a data structure.

The two problem file paths are under test-files so we’ll use the e2a3b7648b57746e68ced4f881f193df05a2341f
hash from the previous command and run git ls-tree again:

$ git ls-tree e2a3b7648b57746e68ced4f881f193df05a2341f
040000 tree 35266afd270f2cf429dd753ab695aacf03ee68d8    Filtered_Data
040000 tree 97ab85ca7728e41e080fe9a9128227d2828108d9    RAW_data_only
040000 tree f55abe3ef151d7209c6cce61878823dc6b2f8801    RAW_output
100644 blob 5020200c10e545c19002f4878c2b6686035f10b0    "SavedData\OpenBCI-RAW-aaron+eva.txt"
100644 blob 0680d8432628eb071aa2c643f11fe8984df6e972    "SavedData\OpenBCI-RAW-friday_test.txt"
100644 blob becc5ab499fb0954c72026fdd78c3517694f5ffa    eeg_filter.m

Excellent, we can see the problem file paths and they correlate to two blobs 5020200c10e545c19002f4878c2b6686035f10b0 and 0680d8432628eb071aa2c643f11fe8984df6e972. These identifiers can be used to find the file contents.

The next step is to read out the contents of those blobs and write them to new
files. I’m going to also create the SavedData directory name again because I
think that was the intent here and someone just used the wrong slash and got
away with it.

$ mkdir test-files/SavedData/

$ git cat-file -p 5020200c10e545c19002f4878c2b6686035f10b0 > test-files/SavedData/OpenBCI-RAW-aaron+eva.txt

$ git cat-file -p 0680d8432628eb071aa2c643f11fe8984df6e972 > test-files/SavedData/OpenBCI-RAW-friday_test.txt

Now we have two new files to commit:

$ git status
On branch fix-path-issue-with-invalid-files
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        test-files/SavedData/

nothing added to commit but untracked files present (use "git add" to track)

$ git add .
warning: LF will be replaced by CRLF in test-files/SavedData/OpenBCI-RAW-aaron+eva.txt.
The file will have its original line endings in your working directory.
gwarning: LF will be replaced by CRLF in test-files/SavedData/OpenBCI-RAW-friday_test.txt.
The file will have its original line endings in your working directory.

I’m not worried about the line ending warning here, and I can confirm this is
accurate once we’ve completed these steps.

Now we can commit these files to the new path:

$ git status
On branch fix-path-issue-with-invalid-files
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   test-files/SavedData/OpenBCI-RAW-aaron+eva.txt
        new file:   test-files/SavedData/OpenBCI-RAW-friday_test.txt


$ git commit -m "add the new files with the correct paths"
[fix-path-issue-with-invalid-files d2a39b6] add the new files with the correct paths
 2 files changed, 131880 insertions(+)
 create mode 100644 test-files/SavedData/OpenBCI-RAW-aaron+eva.txt
 create mode 100644 test-files/SavedData/OpenBCI-RAW-friday_test.txt

Now we have a branch that can be cloned on Windows safely.

Part 3 — Verification

To confirm that line ending warning was a non-issue, I can run the same git ls-tree
command from earlier and confirm the new blobs are unchanged:

$ git ls-tree HEAD
100644 blob 4fda0922d502719782c70810a6d5ddb1c9bdd14d    .gitignore
040000 tree b39c2cabf1b81dba6e7b625ffa2d9e4535e7421f    Dual_Brains_Visualization
100644 blob fa4410c60ac7d6becebdbe43f5560976ae1d207b    README.md
040000 tree 8974c3cb0ae7f8bc05fc891cf481d58235ae5c83    aaron_test_data
040000 tree 68d65ff67f213859f124ed492428eebdb7a5d1ec    drafts
040000 tree 0ca5bae4b0173c9b2f47893136a6d0b299006378    images
040000 tree 7fe38978bb6d446ee4ac3d68a2a3ff006685c8ed    python
100644 blob ca9d99d426f059fdf0c377552d196a22ae2ff47a    requirements.txt
040000 tree 7544e5996262a7fc5017f182790550ab51f92429    test-files

$ git ls-tree 7544e5996262a7fc5017f182790550ab51f92429
040000 tree 35266afd270f2cf429dd753ab695aacf03ee68d8    Filtered_Data
040000 tree 97ab85ca7728e41e080fe9a9128227d2828108d9    RAW_data_only
040000 tree f55abe3ef151d7209c6cce61878823dc6b2f8801    RAW_output
040000 tree 8974c3cb0ae7f8bc05fc891cf481d58235ae5c83    SavedData
100644 blob becc5ab499fb0954c72026fdd78c3517694f5ffa    eeg_filter.m

$ git ls-tree 8974c3cb0ae7f8bc05fc891cf481d58235ae5c83
100644 blob 5020200c10e545c19002f4878c2b6686035f10b0    OpenBCI-RAW-aaron+eva.txt
100644 blob 0680d8432628eb071aa2c643f11fe8984df6e972    OpenBCI-RAW-friday_test.txt

The two files are at the expected new location but still have the old blob hash.

To confirm the clone has been fixed, I cloned down my fork and ask it to
checkout this branch:

$ git clone -b fix-path-issue-with-invalid-files https://github.com/shiftkey/Dual_Brains my-fork
Cloning into 'my-fork'...
remote: Counting objects: 12028, done.
remote: Compressing objects: 100% (23/23), done.
remote: Total 12028 (delta 11), reused 17 (delta 5), pack-reused 12000
Receiving objects: 100% (12028/12028), 56.77 MiB | 7.52 MiB/s, done.
Resolving deltas: 100% (5893/5893), done.
Checking out files: 100% (9136/9136), done.

$ cd my-fork/

$ git status
On branch fix-path-issue-with-invalid-files
Your branch is up to date with 'origin/fix-path-issue-with-invalid-files'.

nothing to commit, working tree clean

Now, you just need to merge this branch into the default branch and everyone
will benefit from this change.