Pourquoi git ne peut pas effectuer de réinitialisations matérielles / logicielles par chemin?

$ git reset -- <file_path> peut réinitialiser par chemin.

Cependant, $ git reset (--hard|--soft) <file_path>signalera une erreur comme ci-dessous:

Cannot do hard|soft reset with paths.

Parce que cela ne sert à rien (d'autres commandes fournissent déjà cette fonctionnalité), et cela réduit le risque de faire la mauvaise chose par accident.

Un "hard reset" pour un chemin est juste fait avec git checkout HEAD -- <path>(vérification de la version existante du fichier).

Une réinitialisation logicielle pour un chemin n'a pas de sens.

Une réinitialisation mixte pour un chemin est ce que git reset -- <path>fait.

Vous pouvez accomplir ce que vous essayez de faire en utilisant git checkout HEAD <path>.

Cela dit, le message d'erreur fourni n'a aucun sens pour moi (car git resetfonctionne très bien sur les sous-répertoires), et je ne vois aucune raison pour laquelle git reset --hardne devrait pas faire exactement ce que vous lui demandez.

La question comment est déjà répondu , je vais expliquer la partie pourquoi .

Alors, que fait git reset ? Selon les paramètres spécifiés, il peut faire deux choses différentes:

• Si vous spécifiez un chemin, il remplace les fichiers correspondants dans l'index par les fichiers d'un commit (HEAD par défaut). Cette action n'affecte pas du tout l'arbre de travail et est généralement utilisée comme l'opposé de git add.

• Si vous ne spécifiez pas de chemin, il déplace la tête de branche actuelle vers un commit spécifié et, avec cela , réinitialise éventuellement l'index et l'arborescence de travail à l'état de ce commit. Ce comportement supplémentaire est contrôlé par le paramètre mode:
  --soft : ne touchez pas l'index et l'arbre de travail.
  --mixed (par défaut): réinitialise l'index mais pas l'arborescence de travail.
  --hard : réinitialise l'index et l'arbre de travail.
  Il existe également d'autres options, voir la documentation pour la liste complète et quelques cas d'utilisation.

  Lorsque vous ne spécifiez pas de validation, la valeur par défaut est HEAD, donc git reset --softne fera rien, car il s'agit d'une commande pour déplacer la tête vers HEAD (à son état actuel). git reset --hard, d'autre part, a du sens en raison de ses effets secondaires , il dit de déplacer la tête vers HEAD et de réinitialiser l'index et l'arbre de travail sur HEAD.

  Je pense qu'il devrait être clair maintenant pourquoi cette opération n'est pas destinée à des fichiers spécifiques de par sa nature - elle est destinée à déplacer une tête de branche en premier lieu, en réinitialisant l'arbre de travail et l'index est une fonctionnalité secondaire.

Assurez-vous de mettre une barre oblique entre l'origine ou l'amont (source) et la branche réelle:

git reset --hard origin/branch

ou

git reset --hard upstream/branch`

Il y a une raison très importante derrière cela: les principes de checkoutetreset .

En termes Git, checkout signifie "intégrer l'arborescence de travail actuelle". Et avec, git checkoutnous pouvons remplir l'arborescence de travail avec des données de n'importe quelle zone, qu'il s'agisse d'un commit dans le référentiel ou de fichiers individuels d'un commit ou de la zone de préparation (qui est même la valeur par défaut).

À son tour, git reset n'a pas ce rôle. Comme son nom l'indique, il réinitialisera la référence actuelle mais en ayant toujours le référentiel comme source, indépendamment du "reach" (--soft, --mixed ou --hard).

Résumer:

• checkout : De n'importe où (index / repo commit) -> arbre de travail
• reset : commit Repo -> Overwrite HEAD (et éventuellement index et arbre de travail)

Par conséquent, ce qui peut être un peu déroutant, c'est l'existence de git reset COMMIT -- filescar "écraser HEAD" avec seulement quelques fichiers n'a pas de sens!

En l'absence d'explication officielle, je ne peux que spéculer que les développeurs git ont trouvé que resetc'était toujours le meilleur nom d'une commande pour annuler les modifications apportées à la zone de préparation et, étant donné que la seule source de données était le référentiel, alors " étendons le fonctionnalité »au lieu de créer une nouvelle commande.

C'est donc git reset -- <files>déjà un peu exceptionnel: il n'écrasera pas la HEAD. IMHO toutes ces variations seraient des exceptions. Même si nous pouvons concevoir une --hardversion, d'autres (par exemple --soft) n'auraient pas de sens.

Explication

Le git resetmanuel répertorie 3 modes d'appel:

• 2 sont au niveau des fichiers: ils n'affectent pas l'arborescence de travail , mais fonctionnent uniquement sur les fichiers de l'index spécifié par <paths>:

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

• 1 est commise: fonctionne sur tous les fichiers référencés <commit>et peut affecter l'arborescence de travail:

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

Il n'y a pas de mode d'appel qui n'opère que sur les fichiers spécifiés et affecte l'arborescence de travail.

solution de contournement

Si vous voulez les deux:

• Réinitialiser la version d'index / cache d'un ou plusieurs fichiers
• Extraire le (s) fichier (s) (c'est-à-dire faire correspondre l'arborescence de travail à l'index et à la version de validation)

Vous pouvez utiliser cet alias dans votre fichier de configuration git:

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

Vous pouvez ensuite effectuer l'une des opérations suivantes:

$ git reco <paths>

$ git reco <branch/commit> <paths>

$ git reco -- <paths>

(Mnenonic pour reco: reset && check out)

git reset --soft HEAD ~ 1 nom de fichier annule la validation mais les modifications restent en local. le nom de fichier peut être - pour tous les fichiers validés