Краткий обзор
git-read-tree
Для поддеревьев я бы посмотрел на
git read-tree -u --prefix dir1/ HEAD:dir2
Это не будет выполнять слияние (git read-tree --merge не поддерживает --prefix одновременно ...)
ручное решение
В противном случае лучшее, что вы можете сделать, это, вероятно,
basecommitish='HEAD^'
git show "$basecommitish":dir1/a" > /tmp/a.orig
git show HEAD:dir2/b > /tmp/b.new
git merge-file dir1/a /tmp/a.orig /tmp/b.new
Этоработал для моего тестового репозитория, что привело к правильному слиянию с изменениями dir1/a
и dir2/b
.
Обнаружение базовых ревизий
К сожалению, поиск правильной ревизии баса для слияния может быть проблемой, поскольку git merge-base
не будет работать для других ссылок на объекты, кроме идентификаторов коммитов.
Поиск последней ревизии, в которой файлы были идентичны
Итак, вот фрагмент, который поможет вам начать поиск ревизии, в которой оба файла были синхронизированы (просматривая только содержимое):
git rev-list HEAD | while read sha1
do
blob1=$(git rev-list --objects $sha1:dir1/a)
blob2=$(git rev-list --objects $sha1:dir2/b)
echo $sha1: $blob1 $blob2
if [ "$blob1" == "$blob2" ];
then
echo Match;
break;
fi
done
Вывод на мой тест-репо:
c5a6b97712d9ebd49146dad6523b2bbc33aea7c0: 4ce3b294e6408ace53b50127aafb2c9308caacf1 e913153db7650d7b8e947066652cf21388552812
7b75768fd3434c867d3741cf07044bf04ef1cc79: 03b82631ac519bf10c20bb12d3b1b03b872dd087 03b82631ac519bf10c20bb12d3b1b03b872dd087
Match
Вы можете легко включить любые ревизии, которые могут существовать в других ветвях, заменив git rev-list HEAD
на git rev-list --all
.
Поиск пары ревизий, в которых файлы были идентичны
Более сложный скрипт, который будет искать совпадающее содержимое в несоответствующих ревизиях путем выполнения вложенных циклов, будет
function findblobs()
{
for path in "$@";
do
git rev-list HEAD | while read sha1
do
echo $sha1 $(git rev-list --objects "$sha1:$path")
done | uniq -f 1
done
}
Теперь вы можете найти ту же информацию, выполнив
findblobs dir1/a dir2/b | sort -k2 | uniq -Ddf 1
// output on testrepo again:
7b75768fd3434c867d3741cf07044bf04ef1cc79 03b82631ac519bf10c20bb12d3b1b03b872dd087
7b75768fd3434c867d3741cf07044bf04ef1cc79 03b82631ac519bf10c20bb12d3b1b03b872dd087
// force multiple hits across several revisions:
git show 7b75768fd3:dir1/a > dir2/b && git commit -am 'force synch with 7b75768fd3'
findblobs dir1/a dir2/b | sort -k2 | uniq -Ddf 1
// output is now:
46b8748f121f8842d936994fa09ad1a81b35d3cc 03b82631ac519bf10c20bb12d3b1b03b872dd087
7b75768fd3434c867d3741cf07044bf04ef1cc79 03b82631ac519bf10c20bb12d3b1b03b872dd087
7b75768fd3434c867d3741cf07044bf04ef1cc79 03b82631ac519bf10c20bb12d3b1b03b872dd087
Поскольку sort(1)
использует стабильную сортировку, вы можете полагаться на хэш первого коммита, соответствующий dir1/a
, а второй - dir2/b
в этом примере звонка ( обратите внимание на порядок звонков на findblobs
)