Если вы можете восстановить временную метку, когда вы клонировали репо, я бы посмотрел наиболее близкий к нему коммит и отошел от него.В противном случае у вас будет сложное время.
По сути, вы запрашиваете минимальное расстояние редактирования между вашим кодом и git-репо, что является трудной проблемой для NP, и в этом случае плохой, посколькувам нужны различия дерева и расстояние редактирования каждого git-объекта (то есть файлов кода и других объектов).
Вы можете попытаться найти иголку в стоге сена с помощью git-tree-diff , сначала клонируя репозиторий плагина, создавая ветку, а затем фиксируя все ваши изменения поверх нее.После этого tree-diff позволит вам оценить разницу, но тогда вам придется повторять это для каждого коммита, и это будет ад.
Вместо этого я бы взял ваш текущий код, сделайте вышеописанное, чтобы выможно получить один огромный diff из HEAD мастера репозитория плагина, а затем попытаться разделить ваши изменения на столько атомных коммитов , сколько сможете.
Это будет больно, но вы можетесм. конец.
РЕДАКТИРОВАТЬ: вот альтернатива, которая может оказаться гибкой, хотя все еще раздражает.Поскольку у вас есть история и вы можете получить самую раннюю версию, вы можете рассчитать хэш-объекты git для «оригинальных» файлов и найти их в истории репо владельца.В своей истории проверьте плагин, прежде чем вносить какие-либо изменения.Это позволит вам вычислить хэш BLOB-объекта для каждого отдельного файла и его содержимого.Затем вы можете выполнить поиск по истории git в официальном репозитории для найденных хэшей BLOB-объектов.Это определит, в какой момент, в частности, в какой момент фиксации файл плагина находился в момент его первоначальной установки.Затем вы можете сравнить и найти самый старый коммит.
В kernel.org git docs приведен пример, позволяющий это сделать:
git log --raw --abbrev=40 --pretty=oneline |
grep -B 1 `git hash-object filename`
Это поможет вам найтипередайте с хэшем, автором и отметкой времени.Я попытаюсь придумать способ дальнейшей автоматизации этого процесса.