git-read-tree - En ligne dans le Cloud

PROGRAMME:

Nom

git-read-tree - Lit les informations de l'arborescence dans l'index

SYNOPSIS

jet arbre de lecture [[-m [--trivial] [--agressif] | --reset | --préfixe= ]
[-u [--exclude-per-directory= ] | -je]]
[--index-output= ] [--pas de caisse clairsemée]
(--vide | [ [ ]])

DESCRIPTION

Lit l'arborescence des informations données par dans l'index, mais ne
Mise à jour l'un des fichiers qu'il "met en cache". (voir: git-checkout-index(1))

En option, il peut fusionner une arborescence dans l'index, effectuer une fusion rapide (c'est-à-dire bidirectionnelle),
ou une fusion à 3 voies, avec l'indicateur -m. Lorsqu'il est utilisé avec -m, l'indicateur -u le fait également
mettre à jour les fichiers dans l'arbre de travail avec le résultat de la fusion.

Les fusions triviales sont effectuées par jet arbre de lecture lui-même. Seuls les chemins en conflit seront dans
état non fusionné lorsque jet arbre de lecture résultats.

OPTIONS

-m
Effectuez une fusion, pas seulement une lecture. La commande refusera de s'exécuter si votre fichier d'index
a des entrées non fusionnées, indiquant que vous n'avez pas terminé la fusion précédente vous
commencé.

--réinitialiser
Identique à -m, sauf que les entrées non fusionnées sont supprimées au lieu d'échouer.

-u
Après une fusion réussie, mettez à jour les fichiers dans l'arbre de travail avec le résultat de la
fusionner.

-i
Habituellement, une fusion nécessite que le fichier d'index ainsi que les fichiers de l'arbre de travail soient
à jour avec le head commit actuel, afin de ne pas perdre les modifications locales. Ce drapeau
désactive la vérification avec l'arbre de travail et est destiné à être utilisé lors de la création d'une fusion
d'arbres qui ne sont pas directement liés à l'état actuel de l'arbre de travail dans un
fichier d'index temporaire.

-n, --exécution à sec
Vérifiez si la commande génère une erreur, sans mettre à jour l'index ou les fichiers dans le
arbre de travail pour de vrai.

-v
Afficher la progression de l'extraction des fichiers.

--banal
Restreindre la fusion à trois voies par jet arbre de lecture se produire uniquement s'il n'y a pas de niveau fichier
fusion requise, au lieu de résoudre la fusion pour des cas triviaux et de laisser des conflits
fichiers non résolus dans l'index.

--agressif
Généralement une fusion à trois voies par jet arbre de lecture résout la fusion pour les cas vraiment triviaux
et laisse d'autres cas non résolus dans l'index, afin que les porcelaines puissent mettre en œuvre
différentes politiques de fusion. Ce drapeau permet à la commande de résoudre quelques cas supplémentaires
intérieurement:

· lorsqu'un côté supprime un chemin et que l'autre côté laisse le chemin non modifié. Les
la résolution est de supprimer ce chemin.

· lorsque les deux côtés suppriment un chemin. La résolution est de supprimer ce chemin.

· lorsque les deux côtés ajoutent un chemin à l'identique. La résolution est d'ajouter ce chemin.

--préfixe= /
Conservez le contenu de l'index actuel et lisez le contenu du tree-ish nommé sous le
répertoire à . La commande refusera d'écraser les entrées déjà
existait dans le fichier d'index d'origine. Notez que le / la valeur doit se terminer par un
sabrer.

--exclude-per-directory=
Lors de l'exécution de la commande avec les options -u et -m, le résultat de la fusion peut nécessiter
écraser les chemins qui ne sont pas suivis dans la branche actuelle. La commande habituellement
refuse de procéder à la fusion pour éviter de perdre un tel chemin. Cependant cette sécurité
la vanne gêne parfois. Par exemple, il arrive souvent que l'autre branche
ajouté un fichier qui était un fichier généré dans votre succursale, et la soupape de sécurité
se déclenche lorsque vous essayez de basculer vers cette branche après avoir exécuté make mais avant d'exécuter
make clean pour supprimer le fichier généré. Cette option indique à la commande de lire
fichier d'exclusion par répertoire (généralement .gitignore) et permet un tel non suivi mais
fichier explicitement ignoré à écraser.

--index-output=
Au lieu d'écrire les résultats dans $GIT_INDEX_FILE, écrivez l'index résultant dans
le fichier nommé. Pendant l'exécution de la commande, le fichier d'index d'origine est verrouillé avec
le même mécanisme que d'habitude. Le fichier doit permettre d'être rebaptiser(2) intégré à partir d'un
fichier temporaire qui est créé à côté du fichier d'index habituel ; généralement cela signifie qu'il
doit être sur le même système de fichiers que le fichier d'index lui-même, et vous devez écrire
l'autorisation aux répertoires dans lesquels se trouvent le fichier d'index et le fichier de sortie d'index.

--no-sparse-paiement
Désactivez la prise en charge du paiement fragmenté même si core.sparseCheckout est défini sur true.

--vide
Au lieu de lire le ou les objets de l'arbre dans l'index, videz-le simplement.


L'identifiant du ou des objets de l'arbre à lire/fusionner.

FUSIONNER

Si -m est spécifié, jet arbre de lecture peut effectuer 3 types de fusion, une seule fusion d'arbre si
un seul arbre est donné, une fusion rapide avec 1 arbres, ou une fusion à 2 voies si 3 arbres sont
à condition de.

Simple Arbre aller
Si un seul arbre est spécifié, jet arbre de lecture fonctionne comme si l'utilisateur n'avait pas spécifié -m,
sauf que si l'index d'origine a une entrée pour un chemin d'accès donné, et le contenu de
le chemin correspond à l'arbre en cours de lecture, les informations statistiques de l'index sont utilisées. (En d'autre
mots, les stat() de l'index sont prioritaires sur celles de l'arbre fusionné).

Cela signifie que si vous faites un git read-tree -m suivi d'un git checkout-index -f
-u -a, le jet index de paiement ne vérifie que les éléments qui ont vraiment changé.

Ceci est utilisé pour éviter les faux résultats inutiles lorsque jet fichiers diff est exécuté après jet
arbre de lecture.

Deux Arbre aller
Typiquement, cela est invoqué comme git read-tree -m $H $M, où $H est le commit principal du
référentiel actuel, et $M est la tête d'un arbre étranger, qui est simplement en avance sur $H
(c'est-à-dire que nous sommes dans une situation d'avance rapide).

Lorsque deux arbres sont spécifiés, l'utilisateur dit jet arbre de lecture ce qui suit:

1. L'index et l'arbre de travail actuels sont dérivés de $H, mais l'utilisateur peut avoir des
les changements depuis $H.

2. L'utilisateur souhaite avancer rapidement jusqu'à $M.

Dans ce cas, la commande git read-tree -m $H $M s'assure qu'aucune modification locale n'est perdue
à la suite de cette "fusion". Voici les règles de "report", où "I" désigne le
index, « propre » signifie que l'index et l'arbre de travail coïncident, et « existe »/« rien » fait référence à
la présence d'un chemin dans le commit spécifié :

Résultat IHM
-------------------------------------------------------
0 rien rien rien (n'arrive pas)
1 rien rien n'existe utiliser M
2 rien n'existe rien supprimer le chemin de l'index
3 rien n'existe, utilisez M si "paiement initial",
H == M garder l'index sinon
existe, échouer
H !=M

nettoyer I==HI==M
------------------
4 oui N/A/A rien rien garder index
5 non N/A/A rien rien garder index

6 oui N/A oui rien n'existe conserver l'index
7 non N/A oui rien n'existe garder l'index
8 oui N/A non rien n'existe échouer
9 non N/A non rien n'existe échouer

10 oui oui N/A n'existe rien supprimer le chemin de l'index
11 non oui N/A existe rien échouer
12 oui non N/A existe rien échouer
13 non non N/A existe rien échouer

propre (H==M)
------
14 oui existe existe garder l'index
15 non existe garder l'index

nettoyer I==HI==M (H!=M)
------------------
16 oui non non existe existe échouer
17 non non non existe existe échouer
18 oui non oui existe existe garder index
19 non non oui existe existe garder index
20 oui oui non existe existe utiliser M
21 non oui non existe existe échouer

Dans tous les cas de "conserver l'index", l'entrée d'index reste telle que dans le fichier d'index d'origine. Si la
l'entrée n'est pas à jour, jet arbre de lecture conserve intacte la copie dans l'arbre de travail lorsque
fonctionnant sous le drapeau -u.

Lorsque cette forme de jet arbre de lecture revient avec succès, vous pouvez voir lequel des "
les modifications" que vous avez apportées ont été reportées en exécutant git diff-index --cached $M. Remarque
que cela ne correspond pas nécessairement à ce que git diff-index --cached $H aurait produit
avant une telle fusion de deux arbres. C'est à cause des cas 18 et 19 --- si vous aviez déjà
les changements dans $M (par exemple, vous l'avez peut-être récupéré par e-mail sous la forme d'un correctif), git diff-index
--cached $H vous aurait informé du changement avant cette fusion, mais cela ne s'afficherait pas
dans git diff-index --cached $M sortie après la fusion de deux arbres.

Le cas 3 est légèrement délicat et nécessite une explication. Le résultat de cette règle logiquement
devrait être de supprimer le chemin si l'utilisateur a organisé la suppression du chemin, puis de basculer
à une nouvelle succursale. Cela empêchera cependant le paiement initial de se produire, de sorte que le
La règle est modifiée pour n'utiliser M (nouvel arbre) que lorsque le contenu de l'index est vide.
Sinon, la suppression du chemin est conservée tant que $H et $M sont identiques.

3-Way aller
Chaque entrée "index" a deux bits d'état "stade". l'étape 0 est la normale, et est
le seul que vous verriez dans n'importe quel type d'utilisation normale.

Cependant, lorsque vous faites jet arbre de lecture avec trois arbres, la "scène" commence à 1.

Cela signifie que vous pouvez faire

$ git read-tree -m

et vous vous retrouverez avec un index avec tous les entrées dans « stage1 », tous les
entrées dans « stage2 » et tous les entrées dans "étape2". Lors de l'exécution d'un
fusion d'une autre branche dans la branche courante, nous utilisons l'arbre d'ancêtre commun comme
, le chef de branche actuel en tant que , et l'autre chef de branche comme .

Les inspections régulières contribuent également à la sécurité des passagers. En identifiant et en traitant les risques potentiels pour la sécurité, tels que des freins usés, un éclairage défectueux ou le remplacement du revêtement de sol, les inspections permettent de réduire le risque d'accidents et de blessures et d'améliorer la sécurité générale du service. Les inspections régulières sont un moyen concret de mettre en valeur l'engagement des prestataires de services de transport en faveur du bien-être des passagers et des conducteurs. jet arbre de lecture a une logique de cas particulier qui dit : si vous voyez un fichier qui
correspond à tous égards aux états suivants, il « s'effondre » à « stage0 » :

· les stades 2 et 3 sont les mêmes ; prendre l'un ou l'autre (ça ne fait aucune différence - le même
des travaux ont été effectués sur notre branche à l'étape 2 et leur branche à l'étape 3)

· l'étape 1 et l'étape 2 sont identiques et l'étape 3 est différente ; prendre l'étape 3 (notre succursale à
le stade 2 n'a rien fait depuis l'ancêtre au stade 1 alors que leur branche au stade
3 ont travaillé dessus)

· l'étape 1 et l'étape 3 sont les mêmes et l'étape 2 est différente prenez l'étape 2 (nous l'avons fait
quelque chose alors qu'ils ne faisaient rien)

La jet arbre-écriture La commande refuse d'écrire un arbre absurde, et elle se plaindra de
entrées non fusionnées s'il voit une seule entrée qui n'est pas à l'étape 0.

OK, tout cela ressemble à une collection de règles totalement absurdes, mais c'est en fait
exactement ce que vous voulez pour faire une fusion rapide. Les différentes étapes représentent la
"arbre de résultats" (étape 0, alias "fusionné"), l'arbre d'origine (étape 1, alias "orig"), et le
deux arbres que vous essayez de fusionner (étapes 2 et 3 respectivement).

L'ordre des étapes 1, 2 et 3 (d'où l'ordre de trois ligne de commande
arguments) sont importants lorsque vous démarrez une fusion à trois avec un fichier d'index qui est déjà
peuplé. Voici un aperçu du fonctionnement de l'algorithme :

· si un fichier existe au format identique dans les trois arborescences, il sera automatiquement
s'effondrer à l'état « fusionné » en jet arbre de lecture.

· un fichier qui a tous différence quoi que ce soit dans les trois arbres restera aussi séparé
entrées dans l'index. C'est à la « politique de la porcelaine » de déterminer comment supprimer le
étapes non 0, et insérez une version fusionnée.

· le fichier d'index enregistre et restaure avec toutes ces informations, vous pouvez donc fusionner des éléments
incrémentalement, mais tant qu'il a des entrées dans les étapes 1/2/3 (c'est-à-dire, "unmerged
entrées"), vous ne pouvez pas écrire le résultat. Alors maintenant, l'algorithme de fusion finit par être vraiment
simple:

· vous parcourez l'index dans l'ordre et ignorez toutes les entrées de l'étape 0, car elles ont
déjà été fait.

· si vous trouvez un "stage1", mais aucun "stage2" ou "stage3" correspondant, vous savez qu'il a été
supprimé des deux arbres (il n'existait que dans l'arbre d'origine), et vous supprimez
cette entrée.

· si vous trouvez un arbre "stage2" et "stage3" correspondant, vous en supprimez un, et
transformer l'autre en une entrée "stage0". Supprimez toute entrée "stage1" correspondante si elle
existe aussi. .. toutes les règles triviales normales ..

Vous utiliseriez normalement jet index de fusion avec fourni jet fusionner-un-fichier faire ça en dernier
étape. Le script met à jour les fichiers dans l'arbre de travail au fur et à mesure qu'il fusionne chaque chemin et au
fin d'une fusion réussie.

Lorsque vous démarrez une fusion à trois avec un fichier d'index déjà rempli, il est supposé
qu'il représente l'état des fichiers dans votre arbre de travail, et vous pouvez même avoir des fichiers
avec des modifications non enregistrées dans le fichier d'index. On suppose en outre que cet état est
"dérivé" de l'arbre de l'étape 2. La fusion à 3 voies refuse de s'exécuter si elle trouve une entrée dans
le fichier d'index d'origine qui ne correspond pas à l'étape 2.

Ceci est fait pour vous éviter de perdre vos modifications de travail en cours et de mélanger vos
changements aléatoires dans un commit de fusion sans rapport. Pour illustrer, supposons que vous partez de ce que
a été validé en dernier dans votre référentiel :

$ JC=`git rev-parse --verify "HEAD^0"`
$ git checkout-index -f -u -a $JC

Vous faites des éditions aléatoires, sans courir jet index-mise à jour. Et puis vous remarquez que la pointe de
votre arbre "en amont" a avancé depuis que vous avez retiré de lui :

$ git récupère git://.... linus
$ LT=`git rev-parse FETCH_HEAD`

Votre arbre de travail est toujours basé sur votre HEAD ($JC), mais vous avez quelques modifications depuis. Trois façons
merge s'assure que vous n'avez pas ajouté ou modifié d'entrées d'index depuis $JC, et si vous
n'ont pas, alors fait la bonne chose. Donc avec la séquence suivante :

$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT
$ git merge-index git-merge-un-fichier -a
$ echo "Fusionner avec Linus" | \
git commit-tree `git write-tree` -p $JC -p $LT

ce que vous voudriez commettre est une fusion pure entre $JC et $LT sans votre travail en cours
changements, et votre arbre de travail serait mis à jour avec le résultat de la fusion.

Cependant, si vous avez des changements locaux dans l'arbre de travail qui seraient écrasés par ce
fusionner, jet arbre de lecture refusera de s'exécuter pour éviter que vos modifications ne soient perdues.

En d'autres termes, il n'y a pas besoin de s'inquiéter de ce qui n'existe que dans l'arbre de travail. Lorsque
vous avez des changements locaux dans une partie du projet qui n'est pas impliquée dans la fusion, votre
les modifications n'interfèrent pas avec la fusion et sont conservées intactes. Quand ils do interférer, le
la fusion ne démarre même pas (jet arbre de lecture se plaint bruyamment et échoue sans modifier
n'importe quoi). Dans un tel cas, vous pouvez simplement continuer à faire ce que vous étiez au milieu de
faire, et lorsque votre arbre de travail est prêt (c'est-à-dire que vous avez terminé votre travail en cours),
essayez à nouveau la fusion.

CLAIRSEMÉ COMMANDE

"Sparse checkout" permet de remplir le répertoire de travail avec parcimonie. Il utilise le
skip-worktree bit (voir git-update-index(1)) pour indiquer à Git si un fichier dans le
répertoire vaut la peine d'être regardé.

jet arbre de lecture et d'autres commandes basées sur la fusion (jet fusionner, jet caisse...) peut aider
maintenir le bitmap skip-worktree et la mise à jour du répertoire de travail.
$GIT_DIR/info/sparse-checkout est utilisé pour définir le bitmap de référence skip-worktree. Lorsque
jet arbre de lecture doit mettre à jour le répertoire de travail, il réinitialise le bit skip-worktree dans
l'index basé sur ce fichier, qui utilise la même syntaxe que les fichiers .gitignore. Si une entrée
correspond à un modèle dans ce fichier, skip-worktree ne sera pas défini sur cette entrée. Autrement,
skip-worktree sera défini.

Ensuite, il compare la nouvelle valeur skip-worktree avec la précédente. Si skip-worktree tourne
de set à unset, il rajoutera le fichier correspondant. S'il passe de non défini à défini,
ce fichier sera supprimé.

Alors que $GIT_DIR/info/sparse-checkout est généralement utilisé pour spécifier dans quels fichiers se trouvent, vous pouvez
spécifier également quels fichiers sont ne sauraient dans, en utilisant des modèles négatifs. Par exemple, pour supprimer le fichier
indésirable:

/*
!indésirable

Une autre chose délicate consiste à repeupler entièrement le répertoire de travail lorsque vous ne voulez plus
caisse clairsemée. Vous ne pouvez pas simplement désactiver le "sparse checkout" car les bits skip-worktree sont
toujours dans l'index et votre répertoire de travail est encore peu peuplé. Vous devriez
remplir à nouveau le répertoire de travail avec le contenu du fichier $GIT_DIR/info/sparse-checkout comme
suit:

/*

Ensuite, vous pouvez désactiver le paiement clairsemé. Prise en charge de caisse clairsemée dans jet arbre de lecture et similaire
commandes est désactivé par défaut. Vous devez activer core.sparseCheckout pour avoir
prise en charge de caisse clairsemée.

Utilisez git-read-tree en ligne en utilisant les services onworks.net