Как получить вишенку из директорий братьев и сестер? - PullRequest
7 голосов
/ 14 апреля 2011

Я хотел бы использовать git cherry-pick для применения фиксации из одного файла к другому без обнаружения переименования (для многих похожих файлов это приводит к неправильному обнаружению).

(главный) каталог1 / файл

(главный) каталог2 / файл

Но я не знаю, как сказать черри-выбрать соответствующий каталог.

У меня был еще один случай, когда он работал нормально с git-1.7.5.rc1, который теперь поддерживает стратегии слияния -Xsubtree=.

(главный) каталог1 / файл

(ветвь) файл

Я позвонил

git cherry-pick --no-commit -Xsubtree=directory1 branch~95

и он работал нормально, перенося изменения из файла (ветка ~ 95) в (главный) каталог1 / файл без обнаружения переименования.

В первом случае я попытался позвонить git cherry-pick с - Xsubtree=../directory1, но это не сработало. Полагаю, мне нужно как-то сказать git cherry-pick, чтобы он покинул каталог 2, а затем пошел в каталог 1, чтобы применить исправления.

У кого-нибудь есть решение этой проблемы?

1 Ответ

4 голосов
/ 14 апреля 2011

Краткий обзор

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)

...