¿Por qué git no puede hacer restablecimientos duros / suaves por ruta?

$ git reset -- <file_path> Se puede restablecer por ruta.

Sin embargo, $ git reset (--hard|--soft) <file_path>informará un error como el siguiente:

Cannot do hard|soft reset with paths.

Porque no tiene sentido (otros comandos ya proporcionan esa funcionalidad), y reduce la posibilidad de hacer algo incorrecto por accidente.

Acaba de hacer un "restablecimiento git checkout HEAD -- <path>completo " para una ruta (verificando la versión existente del archivo).

Un restablecimiento parcial de una ruta no tiene sentido.

Un restablecimiento mixto para una ruta es lo que git reset -- <path>hace.

Puedes lograr lo que estás tratando de hacer usando git checkout HEAD <path>.

Dicho esto, el mensaje de error proporcionado no tiene sentido para mí (ya que git resetfunciona bien en subdirectorios), y no veo ninguna razón por la git reset --hardque no deba hacer exactamente lo que le está pidiendo.

La pregunta de cómo ya está respondida , explicaré la parte del por qué .

Entonces, ¿qué hace git reset ? Dependiendo de los parámetros especificados, puede hacer dos cosas diferentes:

• Si especifica una ruta, reemplaza los archivos coincidentes en el índice con los archivos de una confirmación (HEAD de forma predeterminada). Esta acción no afecta en absoluto el árbol de trabajo y generalmente se usa como lo contrario de git add.

• Si no especifica una ruta, mueve la cabeza de la rama actual a una confirmación especificada y, junto con eso , opcionalmente restablece el índice y el árbol de trabajo al estado de esa confirmación. Este comportamiento adicional está controlado por el parámetro de modo:
  --soft : no toque el índice ni el árbol de trabajo.
  --mixed (predeterminado): restablece el índice pero no el árbol de trabajo.
  --hard : restablece el índice y el árbol de trabajo.
  También hay otras opciones, consulte la documentación para ver la lista completa y algunos casos de uso.

  Cuando no especifica una confirmación, el valor predeterminado es HEAD, por git reset --softlo que no hará nada, ya que es un comando para mover la cabeza a HEAD (a su estado actual). git reset --hard, por otro lado, tiene sentido debido a sus efectos secundarios , dice mover la cabeza a HEAD y restablecer el índice y el árbol de trabajo a HEAD.

  Creo que ya debería estar claro por qué esta operación no es para archivos específicos por su naturaleza: en primer lugar, está destinada a mover un encabezado de rama, restablecer el árbol de trabajo y el índice es una funcionalidad secundaria.

Asegúrese de poner una barra diagonal entre el origen o el flujo ascendente (fuente) y la rama real:

git reset --hard origin/branch

o

git reset --hard upstream/branch`

Hay una razón muy importante detrás de eso: los principios de checkoutyreset .

En términos de Git, pagar significa "traer al árbol de trabajo actual". Y con git checkoutnosotros podemos llenar el árbol de trabajo con datos de cualquier área, ya sea desde un commit en el repositorio o archivos individuales desde un commit o el área de ensayo (que es el valor predeterminado).

A su vez, git reset no tiene esta función. Como su nombre indica, restablecerá la referencia actual pero siempre tendrá el repositorio como fuente, independientemente del "alcance" (--soft, --mixed o --hard).

Resumen:

• pago : desde cualquier lugar (confirmación de índice / repositorio) -> árbol de trabajo
• restablecer : confirmación de repositorio -> Sobrescribir HEAD (y opcionalmente índice y árbol de trabajo)

Por lo tanto, lo que puede ser un poco confuso es la existencia de, git reset COMMIT -- filesya que "sobrescribir HEAD" con solo algunos archivos no tiene sentido.

En ausencia de una explicación oficial, solo puedo especular que los desarrolladores de git descubrieron que resettodavía era el mejor nombre de un comando para descartar los cambios realizados en el área de preparación y, dado que la única fuente de datos era el repositorio, entonces " ampliemos el funcionalidad "en lugar de crear un nuevo comando.

Entonces, de alguna manera git reset -- <files>ya es un poco excepcional: no sobrescribirá el HEAD. En mi humilde opinión, todas esas variaciones serían excepciones. Incluso si podemos concebir una --hardversión, otras (por ejemplo --soft) no tendrían sentido.

Explicación

El git resetmanual enumera 3 formas de invocación:

• 2 son de archivo: estos no afectan el árbol de trabajo , pero operan solo en los archivos en el índice especificado por <paths>:

  • git reset [-q] [<tree-ish>] [--] <paths>..
  • git reset (--patch | -p) [<tree-ish>] [--] [<paths>...]

• 1 es commit-wise: funciona en todos los archivos de la referencia <commit>y puede afectar el árbol de trabajo:

  • git reset [<mode>] [<commit>]

No hay ningún modo de invocación que funcione solo en archivos específicos y afecte al árbol de trabajo.

Solución alterna

Si quieres ambos:

• Restablecer la versión de índice / caché de un archivo (s)
• Verifique los archivos (es decir, haga que el árbol de trabajo coincida con el índice y la versión de confirmación)

Puede usar este alias en su archivo de configuración de git:

[alias]
  reco   = !"cd \"${GIT_PREFIX:-.}\" && git reset \"$@\" && git checkout \"$@\" && git status --short #"  # Avoid: "fatal: Cannot do hard reset with paths."

Luego puede hacer uno de:

$ git reco <paths>

$ git reco <branch/commit> <paths>

$ git reco -- <paths>

(Mnenonic para reco: reset && check out)

git reset --soft HEAD ~ 1 filename deshace la confirmación pero los cambios permanecen en local. nombre de archivo podría ser - para todos los archivos comprometidos