Comment supprimer git subtree merge

Question

J'ai un projet qui repose sur 2 autres sous-projets qui ont été fusionnés en utilisant la stratégie de fusion sous-arbre (comme et there)? Après un moment, j'ai remarqué que l'un des sous-projets avait son propre cycle de vie dans le projet en cours, donc je voudrais le découpler de l'original, mais je ne sais pas comment y parvenir.

Fondamentalement, j'ai remarqué que les sous-projets sont répertoriés dans le fichier .git/config, donc je me demande s'il suffit de le supprimer à partir de là.

Après la réponse/question de Jakub, j'essaierai d'ajouter plus de détails à ma question. Le projet sur lequel je travaille sur ProjectA dépend d'une bibliothèque LibraryB qui possède son propre dépôt git et son propre cycle de vie. Lors de la configuration de ProjectA, j'ai utilisé la technique de fusion de sous-arborescence pour ajouter la dépendance de LibraryB (les étapes sont exactement celles décrites dans les liens ajoutés avec reconnaissance par VonC). Maintenant, ProjectA a besoin de modifications personnalisées à LibraryB qui ne sont pas assez génériques pour être repoussées dans le référentiel LibraryB. Donc, je voudrais découpler le LibraryB dans ProjectA de son référentiel maître (en découplant je veux dire que LibraryB dans ProjectA ne pourra pas mettre à jour à partir de son référentiel maître et aura son propre historique suivi uniquement dans ProjectA).

Plus de détails: après avoir vérifié mon dépôt ProjectA j'ai compris que la seule référence à Bibliothèque_B vie de référentiel dans ProjectA/.git/config sous la forme:

[remote "gaelib"] 
    url = ../libraries/gaelib 
    fetch = +refs/heads/*:refs/remotes/gaelib/* 

et il n'y a pas git supplémentaires liés informations dans le répertoire Bibliothèque_B a été inclus dans ProjectA (../libraries/gaelib)

Answer 1

Si vous voulez maintenir votre propre version de Bibliothèque_B vous avez quelques options:

• Vous pouvez faire de LibraryB une partie inhérente de votre projet: il suffit de supprimer ou de commenter la section [remote "LibraryB"] dans le fichier de configuration et d'apporter des modifications à LibraryB dans votre projet.

  L'inconvénient est qu'il serait plus difficile d'envoyer des patches pour canonique (tiers) version de Bibliothèque_B

• Vous pouvez continuer à utiliser « sous-arbre » fusion, mais pas de la version canonique de Bibliothèque_B, mais de votre propre clone (fourchette) de cette bibliothèque. Vous devez modifier remote.LibraryB.url pour qu'il pointe vers votre version locale, et votre version locale serait le clone de l'original LibraryB. Notez que vous devez fusionner votre propre branche, et non la branche de suivi à distance de LibraryB canonique. L'inconvénient est que vous devez maintenir un clone séparé, et vous rappeler que vos propres changements (du moins ceux génériques) à LibraryB doivent être faits dans la branche de LibraryB, et pas directement dans ProjectA. Vous voudrez peut-être passer de la fusion 'subtree' qui entrelace l'historique de ProjectA et LibraryB, à plus de séparation qui peut être obtenue en utilisant submodule (tutorial). Dans ce cas, vous auriez un dépôt séparé (fork) de LibraryB, mais ce serait dans la zone de travail de ProjectA; le commit dans ProjectA aurait au lieu d'avoir l'arbre de LibraryB comme sous-arbre, pointeur vers commit dans le dépôt LibraryB. Ensuite, si vous ne voulez pas suivre le développement de LibraryB, il vous suffira de ne pas utiliser 'git submodule update' (et peut-être juste au cas où vous commentez ou supprimez le lien vers la version canonique de LibraryB).

  Ceci a l'avantage de faciliter l'envoi de vos améliorations à LibraryB, et l'avantage que vous apportez des modifications dans la zone de travail de ProjectA. Il a l'inconvénient de devoir apprendre un flux de travail légèrement différent.

  De plus, il existe également un problème de comment passer de la fusion 'sous-arbre' aux sous-modules. Vous pouvez:

  • Passer de fusion sous-arbre à sous-module en créant git dans la sous-arborescence des sous-projets dans le référentiel de travail SuperProject (à savoir « git init » à l'intérieur sous-répertoire approprié + approprié « init sous-module git », etc.). Cela signifie que vous auriez "subtree" jusqu'à un certain point de l'histoire, et sous-module plus tard.
  • Réécrivez l'historique à l'aide de git filter-branch pour remplacer la fusion de sous-arborescence par sous-module. Cela a le désavantage de réécrire l'histoire (grand non si quelqu'un a basé son travail sur l'histoire actuelle), et l'avantage du 'bon démarrage'. Ou vous pouvez attendre un peu pour "split git sous-module" (thread on git mailing list) pour en faire git ...
    Malheureusement Splitting a git repository messages blog retourne "host not found"

J'espère que cette version résout votre problème.

Avertissement:Je l'ai utilisé ni fusion sous-arbre, ni sous-modules, ni git-filtre branche personnellement.

Answer 2

Je ne comprends pas. Si vous avez inclus libraryB dans le référentiel projectA à l'aide de la méthode de fusion de sous-arborescence, vous ne devez pas effectuer de découplage. Vous avez déjà exactement ce dont vous avez besoin:

• Vous pouvez extraire les mises à jour de la bibliothèque B à partir du référentiel libraryB. Ce qui, je suppose, est une bonne chose.

• Vous pouvez valider les modifications de la bibliothèque B dans le référentiel de projectA. Ces modifications resteront locales à ce référentiel à moins que vous ne décidiez de les pousser/tirer vers un autre référentiel. Ils feront partie de l'historique de ProjectA uniquement et ne se propageront pas automatiquement dans le référentiel libraryB.

C'est le point entier de la méthode de fusion de sous-arbre par opposition à la méthode de sous-module. Oui, supprimez cette télécommande pointant vers libraryB à partir du fichier de configuration.

Answer 3

Cela empêchera quiconque d'utiliser votre repo de mettre à jour par inadvertance votre code local de la télécommande.

Il n'y a rien d'autre à faire - vous n'avez tout simplement plus besoin d'utiliser le repo LibraryB.

Answer 4

Il semble que vous souhaitiez "annuler" une fusion de sous-arborescence et la renvoyer en amont. La commande git subtree split devrait le faire.