git format-patch: как мне заставить его игнорировать уже объединенные коммиты?

Question

Я работаю над моей копией репозитория perl на github и создал ветку под названием "perl-d-add-tests-2" для внесения некоторых изменений, где я зафиксировал некоторые коммиты. Я отправил эти коммиты в апстрим, и они были применены в "blead" (основной ветке разработки Perl). Я извлек из репозитория upstream и произвел «git merge» из blead в «perl-d-add-tests-2», и теперь я снова попытался запустить там «git format-patch blead», и вот что происходит:

shlomif@telaviv1:~/Download/unpack/perl/p5/git/perl$ git st
# On branch perl-d-add-tests-2
nothing to commit (working directory clean)
shlomif@telaviv1:~/Download/unpack/perl/p5/git/perl$ git diff blead | cat
shlomif@telaviv1:~/Download/unpack/perl/p5/git/perl$ git format-patch blead
0001-Made-c-line_num-working-again.patch
shlomif@telaviv1:~/Download/unpack/perl/p5/git/perl$ 

Как видно, "git format-patch" по-прежнему генерирует уже примененный коммит. WTF?

Как я могу предотвратить это "git format-patch"? Я хочу только уникальные изменения, и ранее, когда это произошло, мне было приказано открыть еще одну ветку и "git cherry-pick" зафиксировать оттуда, но, очевидно, это решение не может масштабироваться, потому что оно засоряет мой репозиторий ветвями.

Answer 1

Один простой вариант - указать, какие коммиты вы хотите, и не включать старые, уже примененные. Общий синтаксис ссылки на коммиты можно найти в git help rev-parse; в этом случае, например, выражение «последние 5 коммитов в моей текущей ветке» будет выглядеть как

git format-patch HEAD~5

Другой возможностью было бы перебазирование вашей perl-d-add-tests-2 функциональной ветви против текущей blead ветви. IIRC, ваша ранняя работа над этой веткой была случайно сведена в один коммит, когда он был применен к blead, поэтому в этом случае вам, возможно, придется выполнить больше ручной очистки, чем вы ожидаете. Если вы хотите попробовать этот подход, я предлагаю сделать это на одноразовой ветке, чтобы вы ничего не потеряли, если все пойдет плохо.

# pull in upstream changes:
git checkout blead
git pull

# create and switch to a new branch "tmp":
git checkout -b tmp perl-d-add-tests-2

# rebuild this branch against your current "blead" branch:
git rebase blead

Если вам понравились результаты, вы можете использовать временную ветку вместо вашей функциональной ветви:

# delete current feature branch:
git branch -d perl-d-add-tests-2

# rename the temporary branch back to the feature branch's name
git branch -m tmp perl-d-add-tests-2

# switch to the recreated feature branch:
git checkout perl-d-add-tests-2

# generate patches against blead:
git format-patch blead

Обратите внимание, что на шаге git rebase blead вы также можете использовать опцию -i, чтобы в интерактивном режиме указать, какие коммиты будут повторно применены к текущей подсказке blead. Это откроет ваш $EDITOR в повестке дня коммитов для повторного применения; если вы пойдете по этому пути, вы, вероятно, захотите явно удалить коммиты в этой повестке дня, которые уже были применены к upstream blead.

Наконец, вы говорите, что создание новой ветки для этого не может масштабироваться, потому что вы засыпаете свой репозиторий нежелательными ветвями. Тем не менее, Git рад, что вы можете переименовать (git branch -m) или удалить (git branch -d) ветки в любое время. Единственный способ, который может вызвать проблемы, - это если другие репозитории вниз по течению от вас зависели от удаленных или переименованных веток. Но в обычном случае локальной ветки функций, из которой никто не тянет и которую вы планируете отправить в апстрим, когда она будет готова, беспокоиться не о чем. Так что, если предложение выбора вишен звучит для вас хорошо, вы можете сделать это и удалить старую версию своей функциональной ветви.