Поиск места, где исходный код разветвился от git

Question

У меня есть репозиторий git (охватывающий более или менее историю проекта) и отдельные источники (просто архив с несколькими файлами), которые были разветвлены некоторое время назад (на самом деле где-то в 2004 или 2005 году).

Исходные тексты из tarball претерпели довольно много изменений, из которых я хотел бы включить некоторые.Теперь вопрос в том, как выяснить, что на самом деле было точкой ветвления для измененных источников, чтобы получить минимальную разницу в том, что там произошло.

Итак, чего я в основном хочу, так это найти место в истории git, где код наиболее похож на архив исходных текстов, который у меня есть.И я не хочу делать это вручную.

Также стоит упомянуть, что измененные источники включают только подмножество файлов и разделили некоторые файлы на несколько частей.Однако код, который там находится, похоже, претерпел лишь небольшие изменения и несколько дополнений.

Если вы хотите поиграть с этим сами, архив с исходниками находится в здесь и Git размещен по адресу Восхитительный: git://gitorious.org/gammu/mainline.git

Answer 1

В общем случае вам действительно придется изучить каждый коммит, потому что у вас нет возможности узнать, если у вас может быть огромный развал в одном, маленький различий в следующем, то другой огромной разной, затем среда ...

Ваша лучшая ставка, вероятно, будет ограничивать себя конкретными файлами. Если вы рассматриваете всего один файл, не следует занимать много времени, чтобы повторить все версии этого файла (используйте git rev-list <path> Чтобы получить список, так что вам не нужно тестировать каждый коммит). Для каждого Commit, которые изменили файл, вы можете проверить размер дифференциала, а достаточно быстро находить минимум. Сделайте это для нескольких файлов, надеюсь, они согласны!

Лучший способ настроить себя на различие - сделать временный коммит, просто копирование в ваш блокбол, чтобы вы могли назвать ветку tarball сравнить против. Таким образом, вы могли бы сделать это:

git rev-list path/to/file | while read hash; do echo -n "$hash "; git diff --numstat tarball $hash path/to/file; done

Чтобы получить хороший список всех коммуникаций со своими различиями (первые три столбца будут SHA1, количество линий, добавленных, а количество линий удалено). Тогда вы могли бы просто трусить его в awk '{print $1,$2+$3}' | sort -n -k 2, И у вас будет отсортированный список коммитов и их разных размеров!

Если вы не можете ограничить себя небольшими несколькими файлами для тестирования, я мог бы соблазнить передать что-то подобное git-bisect - Просто постарайтесь сузить путь к небольшому дифференцированию, делая предположение, что во всей вероятности, коммиты ближе к вашему лучшему случаю также будут иметь меньшие дифференцировки, и обязывает далеко от нее будет иметь большие дифференциры. (Где-то между методом Ньютона и полный поиск двоичных / сетки, наверное?)

Редактировать: другая возможность, предложенная в Ответ Дугласа, если вы думаете, что некоторые файлы могут быть идентичный Для тех, кто в некоторых коммитах, - это хэш их использовать git-hash-object, а потом посмотрите, какие комбиниты в вашей истории у этого Blob. Есть вопрос с некоторыми отличными ответами о том, как это сделать. Если вы сделаете это с несколькими файлами - предпочтительно, которые часто изменились - вы можете сузить целевую коммитацию довольно быстро.

Answer 2

Не отличное решение, но чтобы получить предположение, из которых можно было бы: предположить, что некоторые из файлов в Tar Ball не были изменены, поскольку они были разветвленными. Бежать Гитический хэш объект Против каждого файла в смоленом шаре, затем ищите эти файлы в репозитории, используя Гит-шоу. Отказ Затем попробуйте найти коммиты, в соответствии с которыми были включены эти файлы, возможно, используя Git WhateNeyed. Отказ Ответ на ваш вопрос может быть, может быть коммит с самыми распространенными файлами, но все равно будет немного удариться и пропустить.

Answer 3

основываясь на том, что сказал araqnid, я придумал 9c6c864426bf88429e77c7e22b5aa78e9295b97a (просто попросил материал между 0.61.0 и HEAD) это, вероятно, не самое лучшее) вы могли бы сделать лучше с чем-то вроде

git rev-list --no-merges --all | while read rev; do patchsize=$(git diff $rev | wc -c); echo $patchsize $rev; done | sort -n | less

предполагая, что вы импортировали архив в git и проверили эту ревизию (я сделал это, отключив, а затем

git init
git add .
git commit -m "import tarball"
git remote add origin git://gitorious.org/gammu/mainline.git

Итак, после того, как вы сделаете это и выполните описанное выше, он должен вывести размер всех различий в порядке возрастания patchsize (первый будет равен 0, поскольку он найдет текущий заголовок), это займет много времени...но он должен найти наименьшее различие...

Answer 4

Как была сделана вилка? Это был клон, который кто-то другой сделал, а затем сделал свою работу? Если это так, то это действительно легко. Все, что вам нужно сделать, это создать локальную ветвь, которая тянет в код из вилки. Гит увидит происхождение раздвоенного ветви, указывающего на один из коммитов из вашего оригинального репозитория и будет «подключать точки», чтобы говорить ... он будет воссоединять историю из вашего оригинального хранилища к вилке.

Вы должны сделать это:

git remote add thefork git://wherever.it.lives/thefork.git

git fetch thefork

git branch -f thefork-branch thefork/branchname

git checkout thefork-branch

На данный момент вы можете запустить gitk и увидеть полную историю разветвленной ветви и вашего местного хранилища и посмотрите, если они соединяются или нет.

Answer 5

Импортируйте файлы в Tarball в ревизию Git, на отдельной ветве или совершенно новую: положение в графике ревизии не важно, мы просто хотим, чтобы он был доступен в виде дерева.

Теперь для каждого пересмотра в мастере, просто развернувшись против этого дерева / ревизии («импортированного») и просто вывод, насколько большой разфтал. Что-то вроде:

git rev-list master | while read rev; do patchsize=$(git diff $rev imported | wc -c); echo $rev $patchsize; done

Таким образом, редакция с самым маленьким размером патча будет «ближайшим», очень грубым правилом. (Одинаковая ревизия будет производить размер патча 0, и все остальное, безусловно, будет ненулевым, а тем больше изменилось, тем больше).

Answer 6

Если у вас есть грубая идея относительно того, где произошла вилка, рассмотрите возможность использования ли Manley's git meld. Отказ (Смотрите также: Просмотр различий ветвей с Meld?.)

Для этого добавьте содержимое Tarball в ваш репозиторий (который вы будете делать в любом случае). После установки Meld и git-meld, бежать

git meld branch_from_tarball commit_to_check &

на разных коммитах до тех пор, пока вы не найдете один с наименьшими различиями. Эта команда откроется meld и просмотрите изменения дерева каталога между указанными коммитами, с помощью идентичных файлов, скрытых. Пример скриншотов:

Мелд показывая два очень разных коммита:

Показываю два аналогичных коммитах: