Выяснить зависимости коммита, который мы пытаемся выбрать

Question

Предположим что-то вроде следующего:

                            HEAD/master     
                             |
A<--B<--C<--D<--E<--F<--G<--J  
        ^
        official 

куда official это ветка.
Я хотел вишни выбрать 2 коммитов official например, филиалE а также J
Обе эти фиксы были исправлениями, затрагивающими те же 3 файла.
Когда я сделал git cherry-pick E все прошло хорошо, но когда я сделал git cherry-pick J У меня есть некоторые конфликты.
Глядя на различия, я понял, что мне нужно также выбрать вишню F, которая внесла изменения в два из этих трех файлов, и это было изменение определения метода, и J было сделано поверх этого.
Так что это было легко исправить, просто сделав git cherry-pick F && git cherry-pick J
Вопрос:
Если я не знал об изменениях, внесенных в эти файлы, и фиксация F была большим коммитом, изменяющим много файлов: есть ли другой способ выяснить, от какого коммита мы пытаемся выбрать вишню, зависит без ручного создания журнала git на файл и собирается совершить коммит?

Answer 1

Есть ли другой способ выяснить, от какого коммита, который мы пытаемся выбрать, зависит без ручного создания в файле git-журнала и фиксации коммитом?

Да есть - я написал git-deps автоматизировать именно эту задачу. Поскольку в настоящее время он принимает диапазон коммитов для анализа, в случае вашего примера вам нужно будет передать ему одноэлементный диапазон, содержащий просто коммит J, а также сказать ему, чтобы исключить любые зависимости, которые уже находятся в official:

git deps --exclude-commits official J^!

За кулисами инструмент будет смотреть на разницу J^ с J, а затем запустить git blame на любые строки, которые удалены или изменены, плюс настраиваемое количество строк окружающего контекста. Это приведет к обнаружению, что одна или несколько строк J удаляет или изменяет исходящий из коммита F поэтому он будет выводить SHA1 коммита F,

git-deps может не только обнаруживать зависимости одного коммита или диапазона коммитов, но и создавать целое дерево зависимостей. Поэтому весь описанный вами сценарий сбора вишни может быть автоматизирован в одну команду:

git deps --recurse --exclude-commits official J^! | \ 
    tsort | \ 
    tac | \ 
    xargs -t git cherry-pick

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

Более удобный перенос коммитов между ветками - наиболее очевидный (но не единственный) вариант использования git-deps и по этой причине я посвятил раздел README специально этому варианту использования. Он даже включает в себя видео на YouTube, показывающее, как именно его использовать.

Если вы хотите получить более подробную информацию, вас могут заинтересовать несколько выступлений, которые я представил по этому и другим связанным инструментам:

• выступление для группы пользователей Git London
• выступление на конференции разработчиков OpenStack

Я также говорил об инструменте в эпизоде ​​№ 32 подкаста GitMinutes.

Answer 2

У меня есть некоторые конфликты [слияния]... Есть ли другой способ выяснить, от какого коммита мы пытаемся выбрать вишню, зависит от...

Не на самом деле нет.

... без ручного создания журнала git для файла и фиксации коммитом?

Даже это не обязательно сделает это - по крайней мере, не задумываясь о проблеме. Рассмотрим следующий фрагмент кода C:

void f(int x) {
    int i;

    /*
     * additional lines here, enough to mess with git context
     * since that only looks at +/- 3 lines around each patch
     * segment
     */

    for (i = 0; i < x; i++)
        do_something(i);
}

Предположим, что один промежуточный коммит вводит дополнительную переменную jи затем внесите изменения do_something(i) в do_something(j), Если вы выберете только поздний коммит, Git с радостью изменит строку без конфликтов, но код больше не будет компилироваться, так как нет int j в функции f,

Тем не менее, можно было бы написать инструмент, который анализирует git show вывод для каждой промежуточной фиксации, определяет, какие строки изменены (относительно версии в рабочем дереве, вместо использования фактических чисел в каждой разнице, поскольку они могут зависеть от предыдущего пропущенного различий), и указывает, что коммиты изменить конфликтующие регионы. Но я не знаю ни одного такого инструмента.