Bifurcar un repository de GitHub usando desde la línea de command con bash, cURL y la API de GitHub

Estoy teniendo problemas con mi script bash para bifurcar un repository de GitHub usando cUrl.
El documento gitHub API para crear un tenedor .

He intentado muchas variaciones:

curl -u $my_user_name https://api.github.com/repos/forks -d "{\"owner\":\"$upstream_repo_username\",\"repo\":\"$upstream_repo_name\"}"

y
curl -u $my_user_name https://api.github.com/repos/'$upstream_repo_username'/'$upstream_repo_name'/forks

produce el siguiente error: { "message": "Not Found", "documentation_url": "https://developer.github.com/v3" }

En contraste, lo siguiente crea un nuevo repository de github vacío, como se esperaba:
curl -u $my_user_name https://api.github.com/user/repos -d "{\"name\":\"$upstream_repo_name\"}"

¿Alguna idea sobre cómo crear un tenedor de un repository desde la línea de command?

Tengo un script bash que: – crea un repository vacío en github con el nombre del repository que voy a clonar, – clona un repository de otro usuario localmente, y – empuja mi repository clonado al repository vacío que creé en mi Cuenta github: establece los controles remotos de origen y de subida apropiadamente

Sin embargo, este método no mantiene una connection dentro de GitHub con el repository fuente (bifurcado). Me gusta especialmente la conveniencia del enlace bifurcado que aparece debajo de mi propio nombre de reserva 😉

El objective es hacer toda mi clonación (y bifurcación) desde la línea de command.

No quiero abrir un browser, navegar al repository que deseo bifurcar, solo para acceder al button "Tenedor". Solo regrese a la línea de command para finalizar el process.

Alternativamente, ¿puedo convertir un repository clonado en uno bifurcado de la línea de command? (es decir, ¿Algún command de línea de command api que volverá a crear esos enlaces internos de github que poseen las horquillas?)

La documentation muestra que el propietario y el repos son parte del URI de request

 curl -d '' https://api.github.com/repos/octocat/Hello-World/forks 

https://developer.github.com/v3/repos/forks/

Esto parece funcionar bien.

Aquí está mi script bash de trabajo:

 curl -u $my_user_name https://api.github.com/repos/$upstream_repo_username/$upstream_repo_name/forks -d '' 

Ejemplo usando cadenas codificadas en lugar de variables bash:

 curl -u 'SherylHohman' https://api.github.com/repos/octocat/Hello-World/forks -d '' 

Observe que moví -d '' al final para evitar errores de inicio de session.
La request requiere authentication.
Proporciono esto a través del parámetro -u de curl (en contraposition al uso de OAuth2).
Cuando utilicé la opción -u $my_user_name ,
Tuve que mover la -d '' después del URI
– resultó en errores de inicio de session si se coloca entre -u 'username' y el URI.

Resulta la principal fuente de errores en mi script con bash-syntax.
Tenía comillas alnetworkingedor de las variables de bash, que no deberían haber estado allí.
(..just Resolver un punto de dolor sin realmente conocer bash o curl)

Además, como señaló #YuriSchimke, este URI particular requirió que los parameters se pasaran en el URI. Pasar estas opciones como json no es una opción, a diferencia del URI para Crear un nuevo repository en blanco.

Esta es la razón por la cual estaba desconcertado sobre cómo enviar estos datos en el URI:

Usando curl, la request pnetworkingeterminada es un GET .
En curl, las requestes POST se realizan agregando el indicador -d (equivalente a --data ) seguido de los datos que se enviarán.

Necesitaba enviar una request POST.
El formatting para la API de GitHub es que las requestes GET (y POST, por ejemplo, CreateRepo ) a veces pueden enviar algunos parameters como json o cadenas de consulta
NOTA: la documentation para la API de GitHub parece estar un poco incompleta, ya que no veo ninguna mención de la API que permita json, solo cadena de consulta.
Supongo que en este caso, los datos se intercalan entre dos partes de URI estáticas, por lo que es imposible enviarlos como valores json.

No sabía cómo usar el indicador -d sin datos :

Si simplemente lo dejé, la llamada API se procesó como un GET.
Devolvió información sobre el repository que quería bifurcar,
en lugar de bifurcar el repo a mi count.

La publicación de @ YuriSchimke me dio ese "¡Ahaa!". ¡Gracias! Me río porque no pasó por mi mente. ¡Estoy agradecido de que Yuri haya hecho esto tan obvio! (Gracias de nuevo).