gitk: странное древо истории - PullRequest
9 голосов
/ 22 декабря 2010

Я портирую svn-репозиторий на git (используя svn2git из https://www.negativetwenty.net/redmine/projects/show/svn2git), и поскольку svn не отслеживает слияния, мне нужно вручную редактировать .git / info / grafts. Для этого я запускаю gitk, search для термина «Слияние» в сообщениях о коммитах убедитесь, что коммиты слияния имеют правильное происхождение и соответственно заполняют .git / info / grafts.

Проблема, с которой я столкнулся, заключается в том, что gitk, похоже, перепутали с веткой "master". Он часто показывает, что мастер «разветвляется» из ветви и сливается в послесловие ветви, хотя на самом деле все наоборот.

Почему он не может понять, что мастер должен быть "настолько линейным", насколько это возможно, и именно ветвь должна быть раздвоена от него, а не наоборот? Это проблема с gitk или история с git repo неполная? Кажется, "git log --pretty = oneline --graph" может показать правильное поведение, поэтому я думаю, что это может быть проблема с gitk.

Я также попробовал giggle и qgit, но у обоих есть свои проблемы. Я нахожу, что дерево хихика трудно понять (например, слияния горизонтальны, в то время как в qgit и gitk они наклонны ...) и qgit, кажется, не показывает некоторые коммиты (коммит, создающий ветку в svn, отображается как коммит git в "git log --pretty = oneline --graph" и gitk, но не в qgit и не хихикают).

Обратите внимание, что в своих тестах я использую "gitk --all".

Итак, мой вопрос: -Как я могу заставить Гитка показать мастера как можно более линейным? Идеально «оправдано влево» с ответвлениями, а не наоборот. "git log --pretty = oneline --graph", кажется, делает это правильно, но как насчет gitk?

Спасибо!

Редактировать: ссылки на скриншоты неактивны. Ранее сказано:

Я загрузил скриншоты различных инструментов: git log, gitk, хихикать, qgit

Посмотрите, как "git log" показывает ветку, сливающуюся в транк, в то время как gitk показывает объединение ствола в ветке. Хихикать и qgit показывает право объединить, но они часто отбрасывают некоторые коммиты (создавая ветки), так что это очень трудно вручную редактировать файл .git / info / grafts.

Ответы [ 3 ]

1 голос
/ 23 декабря 2010

После игры с другим графическим интерфейсом поведение действительно зависит от инструмента. К сожалению, не многие из них являются настраиваемыми ...

Я предпочитаю иметь древовидное представление о том, что произошло на самом деле, а не оптимизированное представление, где все подходит ...

Я согласился на «gitg» (http://trac.novowork.com/gitg/). Кажется относительно активным, и он делает именно то, что я ожидаю от представления истории. Мастер - самый левый «переулок», ответвления от него разветвляются и объединяются с ним из Я чувствую, что это согласуется с моим рабочим процессом. Кроме того, я могу показать «неактивные дорожки», так что мастер всегда отображается и слева, (включить / отключить в окне настроек). Приятной вещью также является «Показать историю в топологическом порядке». Когда проверено, gitg будет пытаться поместить коммиты на ветку вместе. Если флажок не установлен, они будут отображаться в хронологическом порядке.

Он также может выполнять базовые коммиты и постановку.

Единственный недостаток, который я могу найти, - это поиск: кажется, я не могу ввести sha1sum и найти правильный коммит. Может быть, просто ошибка.

Насчет оригинального вопроса (можно ли настроить gitk так, как я хочу?) Я до сих пор не уверен, что это возможно. Вероятно, дизайнерское решение ...

0 голосов
/ 25 декабря 2010

Если у вас есть учетная запись github, вы также можете попробовать посмотреть там « Сеть ».

0 голосов
/ 23 декабря 2010

Посмотрите, как "git log" показывает ветку, сливающуюся в транк, в то время как gitk показывает слияние транка в ветку.

Это потому, что Гитк свободно меняет порядок родителей - как и многие другие инструменты. Крайний левый родитель не всегда является первым родителем. Часто инструменты помещают родителей туда, где есть место. Это в конечном итоге обеспечивает более упакованный вид. Для сравнения:

Я считаю, что графики в git-log не очень эргономичны - они занимают больше пустых строк.

...