2012-02-15 3 views
6

Я переустановил довольно старую ветку темы на мастер. Поскольку во время rebase было довольно много конфликтов, я бы хотел сравнить ветку старой темы с переупомненной, чтобы убедиться, что я случайно не удалял или не вносил никаких изменений в тему. Ближайшим, к которому я пришел, являются результаты git diff master...topic и git diff master...topic-rebased. Этот вид работ, но в последнем различии есть много шума от изменений в коде контекста, номерах строк, хэшах коммита и т. Д., В дополнение к этому это не очень надежное решение. Есть ли более простой способ сделать это?Сравнить ветвь git с переположенной веткой

+0

В зависимости от важности важности стилей вы можете попробовать снова его переустановить и сравнить этот результат с 'subject-rebased' ... (Это работает на предположении, что вы будете более осторожны в разных местах во второй раз .) В противном случае опция -U в 'git diff' может сократить контекст, и вы можете попробовать grepping из заголовков hunk, содержащих номера строк и хэшей blob. – antak

+0

Интересной альтернативой является переустановка его (например, 'master..topic-rebased') обратно на * merge-base * (или откуда когда-либо была« тема ») и сравнить (diff) это с« темой ». Это будет действовать как математическое доказательство, и любые дельта, которые вы видите здесь, должны быть важными. Переустановка здесь может быть выполнена с помощью 'cherry-pick' или' rebase upstream topic ~ 0 --onto new_base'.Я не знаю вашего уровня знаний, но «rebasing back» в этом случае не должен включать в себя шланги ваших текущих ветвей, потому что я ожидаю, что это будет сделано в отдельном состоянии или в откидной ветке. – antak

+0

Возврат обратно не будет работать, так как это приведет к другим конфликтам. –

ответ

4

Вы, наверное, хотели бы, чтобы дифф эффективных изменений (заплаты), производимые каждый:

diff <(git log master..topic -p) <(git log master..old-place-of-topic -p) 

Это позволит эффективно удалить любые изменения, внесенные в мастер.

+0

Исправьте меня, если я ошибаюсь, но это также покажет все изменения из 'git merge-base master topic' в' git merge-base master topic-rebased', чего я не хочу. Мне нужно только просмотреть изменения, относящиеся к ветви темы. Кроме того, нет необходимости в reflog, у меня есть как тема, так и тема, которые все еще доступны. – Ryan

+0

под редакцией. Теперь я получаю то, что тебе нужно. –

+0

Я ценю ответ, но у этого есть тот же самый результат и проблемы (предполагая, что вы имели в виду 'master ... old-place-of-topic') как то, что я сейчас делаю (упомянутый в вопросе). – Ryan

0

Если вам не нужна история фиксации из вашей ветви темы, вы можете выполнить повторную настройку и добавить флаг -squash. Это даст вам одну фиксацию поверх главной ветки, где вы можете и переходить файл измененных файлов по файлу. Я бы также добавил флаг --no-commit для переадресации, чтобы я мог просмотреть изменения до фиксации git rebase.

git checkout master 
git rebase --squash --no-commit topic 
//review changes with your favourite git tool 
git commit 

Если вы не хотите, чтобы повторить Rebase наличия внешних дифференциалы инструменты, такие как KDiff3 могут помочь вам.

+1

Вы не хотите переустанавливать мастера на тему. –

+0

Это правда. Мне пришлось перечитать мой ответ, но я не вижу, где я написал, что мастер должен быть переустановлен по теме? – MikaelHalen

+0

Я не хочу просматривать изменения, внесенные в эту тему, я хочу просмотреть изменения, которые я сделал (в результате конфликтов) во время rebase. – Ryan

4

Я боролся с этой же проблемой и придумал похожие идеи, такие как Райан и Адам Дымитрук, и нашел их не очень удовлетворительными: сравнение окончательного разбора затруднительно и также не показывает вам, где была введена «ошибка», если ты нашел это.

Мой текущий рабочий процесс по перестановке включает в себя сравнение каждой переустановленной фиксации с оригинальной, поэтому я могу выявлять и исправлять потенциальные ошибки по мере их появления и не выполнять повторную переустановку. Я использую следующую пару GIT псевдонима для облегчения этого:

rc = !git diff -w $(cat .git/rebase-merge/stopped-sha) > .git/rebase-merge/current-diff 
rd = !git diff -w $(cat .git/rebase-merge/stopped-sha) | diff --suppress-common-lines .git/rebase-merge/current-diff - | cut -b 1-2 --complement | less 

git rc хранит различий между HEAD последней редакции от филиала, который в настоящее время нормированный. После повторного воспроизведения следующего фиксации git rd сравнивает этот сохраненный diff с разницей между новым HEAD и следующей фиксацией на ветке, которая была переустановлена. Поэтому это показывает, что только различие («ошибка») вводится путем повторного воспроизведения последнего коммита.

После проверки отличия вызовите git rc, чтобы обновить сохраненный diff и продолжить переустановку.

Вместо ручного вызова git rc и git rd вы можете даже добавить их в свой git-rebase-todo, чтобы они вызывались автоматически после повторного воспроизведения каждой фиксации.