Cloning Project w/ Submodules Fails w/ "bash: /dev/tty: No such device or address" Error

[RJ]

When cloning Git projects that have submodules, one must input credentials multiple times, once for the core/parent repo and once for each submodule. To avoid that, it is possible to create an SSH public/private key pair and add the public key to one's Bitbucket user profile. When that is done, a Bitbucket project can be cloned without entering any credentials whatsoever. That's the idea anyway.

However, after setting that up, if the project has submodules and the --recurse-submodules option is used on the git clone command, the process hangs with a bash error. Here's the command being used on Windows 7 using the Git Bash command line:

git clone git@bitbucket.org:[account_owner]/[repo_name].git -b [branch_name] --recurse-submodules [target_directory]

The core/parent repo clones fine without the --recurse-submodules option. When attempting to also clone submodules, the core/parent repo is cloned fine, but once the submdule cloning starts, everything hangs with the following bash error/notice:

bash: /dev/tty: No such device or address

The process must be terminated using CTRL-C.

[Marty · Accepted solution]

Hi RJ,

I am not an expert on submodules but will try to help.

Is it possible that the flag is simply in the wrong place?

Eg. what happens if you try this order instead

git clone --recurse-submodules https://github.com/chaconinc/MainProject

The other options is to clone the submodules individually.  

cd <submodule directory>

git submodule init

git submodule update

I hope that helps!

[RJ]

Thanks for the suggestion. Unfortunately, the behavior is unchanged.

Just to clarify, your example used https for the protocol. Handling submodules recursively via https -- that is without an SSH key pair -- works, but a password is required for each repo. Being that the intent is to use SSH keys to avoid inputting username/password multiple times, it's my understanding that the git protocol needs to be used instead. Protocol formats can be found at https://confluence.atlassian.com/bitbucket/change-the-remote-url-to-your-repository-794212774.html.

I'm currently testing handling each submodule individually, but that approach, like entering username/password multiple times, is not ideal.

[Marty]

Hi RJ,

can I ask how you are executing this command?  Eg. are you typing in the command directly into your terminal?  Or are you executing a script?  Is it inside a Docker container by any chance?

[RJ]

The command is being used on Windows 7 via the Git Bash command line. So, no Docker container.

I also tried the git clone command for the core/parent project, as shown in the original post, but without the --recurse-submodules option. Then within the core/parent folder, initialize and updated the submodules:

git submodule update --init --recursive

 In this case, the protocol used appears to be https, yet the bash error is the same.

[computer_name] MINGW64 ~/[core_project_path] ([core_project_branch_name])
$ git submodule update --init --recursive
Submodule '[submod1_folder_name]' (https://bitbucket.org/[account_owner]/[submod1_repo_name].git) registered for path '[submod1_folder_name]'
Submodule '[submod2_folder_name]' (https://bitbucket.org/[account_owner]/[submod2_repo_name].git) registered for path '[submod2_folder_name]'
Submodule '[submod3_folder_name]' (https://bitbucket.org/[account_owner]/[submod3_repo_name].git) registered for path '[submod3_folder_name]'
Cloning into '[submod1_folder_path]'...
bash: /dev/tty: No such device or address

[Marty]

Hi RJ,

we're making progress here.

I think that the error has nothing to do with your git commands but rather with your bash terminal.

bash: /dev/tty: No such device or address

Bash expects there to be some files in /dev including the tty file representing the current terminal process.

I suspect that things are not at parity in the window bash you're using vs. bash on unix.

I'd recommend investigating the setup for your git bash.

I hope that helps!

[RJ]

Uninstalling Git For Windows v2.18.0 and installing v2.21.0 appears to have resolved the bash error, as previously described. Using a CLI command similar to that shown in the original post, the submodules can now be cloned, along with the core/parent project, without error and without needing to satisfy multiple authentication requests.

Interestingly, the core/parent repo is cloned using SSH (no interactive authentication needed). However, when the clone operation gets to its first submodule, it prompts once for authentication (in a browser pop-up showing an Atlassian login page), then completes fine. So the submodules appear to still be using HTTPS authentication, which is evidently cached, not the SSH key. This is clearly a different issue than the original post, but wanted to make note of it. Even so, this workflow is much improved over needing to enter credentials multiple times.

Thanks for your help.