Si vous pouvez récupérer l'horodatage lorsque vous clonez le repo, je rechercherais le commit le plus proche de celui-ci et le branchement à partir de là. Sinon, vous allez avoir un temps poilu.
Vous demandez essentiellement la distance d'édition minimum entre votre code et un repo git, qui est un problème NP-difficile, et un mauvais dans ce cas, car vous avez besoin des différences et de la distance d'édition de chaque git blob (c'est-à-dire, les fichiers de code et d'autres objets).
Vous pouvez essayer de trouver une aiguille dans la botte de foin avec l'aide de git-tree-diff, en clonant d'abord le repo du plugin, en faisant une branche, puis en validant toutes vos modifications par-dessus. tree-diff vous laissera ensuite évaluer la différence, mais vous devrez répéter ceci pour chaque commit, et ce sera l'enfer. Au lieu de cela, je prendrais votre code actuel, faites le ci-dessus afin que vous puissiez obtenir un énorme diff de la tête HEAD du plugin repo, puis essayez de split your changes into as many atomic commits comme vous le pouvez.
Ça va faire mal, mais vous pourriez en voir la fin.
EDIT: voici une alternative qui peut se révéler traitable, bien qu'encore agaçante. Puisque vous avez l'historique et que vous pouvez obtenir la première version, vous pouvez calculer les blobs de hachage git pour les fichiers "originaux" et les trouver dans l'historique du dépôt du propriétaire. Dans votre historique, consultez le plugin avant d'apporter des modifications. Cela vous permettra de calculer le hachage de blob pour chaque fichier individuel et son contenu. Vous pouvez ensuite faire une recherche à travers l'histoire git sur le rapport officiel pour les hachages blob que vous trouvez. Cela permettra d'identifier à quel moment, en particulier à quel commit, le fichier plugin était à l'origine lorsque vous l'avez installé. Ensuite, vous pouvez comparer et trouver le plus ancien commit.
Le kernel.org git docs donner un exemple de faire ceci:
git log --raw --abbrev=40 --pretty=oneline |
grep -B 1 `git hash-object filename`
Vous trouverez le commit w/hachage, l'auteur et l'horodatage. Je vais essayer de penser à un moyen d'automatiser cela plus facilement.
Que voulez-vous dire par «des correctifs locaux ont été ajoutés? Travaillez-vous sur un repo cloné et les avez-vous engagés, ou juste appliqué un tas de changements et avez le code maintenant? – shelhamer
Un certain nombre de modifications ont été appliquées au repo du superprojet, nous connaissons donc l'historique et pouvons obtenir la première version du plugin; mais nous ne savons pas ce que le commit était dans le propre dépôt du plugin. – Alexy
J'ai réfléchi à ce sujet et j'ai cherché des docs sur git hash-object, qui produit le hash blob pour les fichiers et leur contenu. Puisque vous avez l'historique et que vous pouvez obtenir la version la plus ancienne, vous pouvez calculer les hachis de hachage pour les fichiers "originaux" et les trouver dans l'historique du dépôt du propriétaire. – shelhamer