Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.35.1 → 2.55.0 no changes
-
2.35.0
2022-01-24
- 2.24.1 → 2.34.8 no changes
-
2.24.0
2019-11-04
- 2.1.4 → 2.23.4 no changes
-
2.0.5
2014-12-17
DESCRIPTION
Cela recherche le(s) <fichier>(s) dans l’index et, s’il y a des entrées de fusion, passe le hachage SHA-1 de ces fichiers comme arguments 1, 2, 3 (argument vide si pas de fichier), et <fichier> comme argument 4. Les modes de fichier pour les trois fichiers sont passés comme arguments 5, 6 et 7.
OPTIONS
- --
-
Ne pas interpréter les arguments qui suivent comme options.
- -a
-
Lancer la fusion contre tous les fichiers de l’index qui nécessitent une fusion.
- -o
-
Au lieu de s’arrêter à la première fusion échouée, toutes les effectuer en une seule fois - continuer à fusionner même quand les fusions précédentes ont retourné des erreurs, et ne retourner le code d’erreur qu’après toutes les fusions.
- -q
-
Ne pas se plaindre d’un programme de fusion échoué (un échec du programme de fusion indique généralement des conflits pendant la fusion). C’est pour les interfaces de haut niveau qui pourraient vouloir émettre des messages personnalisés.
Si git merge-index est appelé avec plusieurs <fichier>s (ou -a), il les traite à tour de rôle en s’arrêtant uniquement si la fusion retourne un code de sortie non nul.
Typiquement, cela est exécuté avec un script appelant l’imitation par Git de la commande merge du paquet RCS.
Un exemple de script appelé git merge-one-file est inclus dans la distribution.
ALERTE ALERTE ALERTE ! L’ordre des objets de fusion de Git est différent de l’ordre des objets de fusion du programme merge de RCS. Dans l’ordre ci-dessus, l’original est en premier. Mais l’ordre des arguments du programme de fusion à 3 sens merge est d’avoir l’original au milieu. Ne me demandez pas pourquoi.
Exemples :
torvalds@ppc970:~/merge-test> git merge-index cat MM This is MM from the original tree. # original This is modified MM in the branch A. # merge1 This is modified MM in the branch B. # merge2 This is modified MM in the branch B. # current contents
ou
torvalds@ppc970:~/merge-test> git merge-index cat AA MM cat: : No such file or directory This is added AA in the branch A. This is added AA in the branch B. This is added AA in the branch B. fatal: merge program failed
où le dernier exemple montre comment git merge-index cessera d’essayer de fusionner dès que quelque chose a retourné une erreur (c’est-à-dire que cat a retourné une erreur pour le fichier AA, parce qu’il n’existait pas dans l’original, et donc git merge-index n’a même pas essayé de fusionner MM).
GIT
Fait partie de la suite git[1]
TRADUCTION
Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .