git-1.6.6 вышел

> АдЪ — это использовать репозитарий в .hg/patches/ по прямому назначению и пытаться что-то понять в дифффах диффов. :)

Это следующий круг :)

Во-первых, как бы ты решал эту задачу известными тебе средствами?

Примерно как AlexM описал для Git - послать ревьюеру bundle, чтобы он его импортировал и поправил, где надо. Если правки не потребуют введения новых патчей или фолдинга существующих, процедура относительно терпимая. Или можно пойти путем LKML - запостить сами патчи в лист рассылки, и править их самому по собранным отзывам.

Во-вторых, как бы ты хотел, чтобы она решалась?

Не знаю. Я даже pbranch пока не пользовался.

> для Git (шаги 5 и 6 - это просто песня).

Ой, у вас, ртутников, какие-то странные фобии^W опасения относительно rebase'а. Нормальная операция; делается быстро; если известно, что это не последний ребэйз для данной цепочки, то не грех и воспользоваться инструментами типа git-rerere, для того, чтобы не резолвить многократно одни и те же конфликты относительно основной цепи изменений. В общем, «чего нас бояться»...

В общем, я согласен с тем, что анализ разницы между двумя ветками может занимать много усилий, а вот приведение цепочки в актуальное по сравнению с основной веткой состояние - работа несложная.

И в CVS, и в SVN, и везде, бранч - это именованный набор изменений

Строго говоря, не совсем так. Бранчи служат для того, чтобы фиксировать последовательности независимых друг от друга изменений в проекте. И в этом смысле они везде - бранчи. Так, и велосипед, и место пассажира в авиалайнере служат для того, чтобы переместить человека из пункта А в пункт Б со скоростью, превышающей физические возможности человеческой мускулатуры.

Отличия - во внутренней организации. Я знаю проект на CVS'е, состоявшем из множества модулей, в котором бранчевание централизовано делалось чуть ни по расписанию, грубо говоря, вне зависимости от количества изменений, сделанных с прошлого раза в данном модуле.

И при импорте каждого из модулей в SVN при помощи cvs2svn картинка была воистину ужасающей - множество бранчей с единственным отличающимся коммитом в каждом, причём, изменений по сравнению с материнским бранчем - 0. И для SVN это единственный способ втащить из CVS такую (да, слегка, м-м-м, причудливую, но другой не было) схему ведения проекта.

А вот git, как и CVS, рассматривает бранчевание только как *потенциальные* точки появления независимых изменений. Поэтому и лишних коммитов даже при такой схеме там не образуется, и картинка бранчей каждого конкретного модуля в целом заметно более вменяемая.

С любезной помощью авторов cvs2svn, нескольким изменениям, сделанным для cvs2git, который является подпроектом cvs2svn, и паре самописных тулзёвин, пережевывающих git'овую базу, мне вполне удалось затащить проект в git с минимальными потерями здравого смысла.

Другое дело, что в идеологии git бранчи *могут быть* использованы достаточно вольно, и, на самом деле, такое «нетрадиционное» использование поощряется всей практикой работы. Поэтому и возникает потребность в определениях, несколько отличающихся от тех, которые, как Вы думаете, «отлиты в граните». Но ничего не мешает те бранчи, которые вы намереваетесь использовать «нетрадиционным образом», именовать с соответствующим префиксом, не вводя на «железный» уровень дополнительные сущности, вроде букмарков :)

>> для Git (шаги 5 и 6 - это просто песня).

Ой, у вас, ртутников, какие-то странные фобии^W опасения относительно rebase'а

Какого еще rebase? Напомню:

5. Далее вы проводите сравнение Вашей the_feature с friend/the_feature, используя, например, команды git diff (ну, это понятно), git cherry (автоматический поиск изменений в другой ветке, не применённых в текущей) и так далее.

6. При необходимости вы меняете какие-то из коммитов в своей ветка the_feature, может быть, повторяете шаги 2-5, ну, в общем, до момента обоюдного удовлетворения

Ни в одном из пунктов rebase не упоминается.

Нормальная операция; делается быстро; если известно, что это не последний ребэйз для данной цепочки

Блин, да о каком rebase речь? У тебя две цепочки, с единым корнем, причем тут _rebase_?

И, просто для протокола - нет у нас фобий относительно rebase.

И в CVS, и в SVN, и везде, бранч - это именованный набор изменений

Строго говоря, не совсем так

По крайней мере в SVN - совсем так. CVS уже не помню, но, IIRC, в ,v-файлах есть метки бранчей. А в Git при clone информация о бранчах не копируется, к какому бранчу принадлежит коммит - ХЗ.

А вот git, как и CVS, рассматривает бранчевание только как *потенциальные* точки появления независимых изменений

Git рассматривает так любой коммит (и Mercurial тоже).

Другое дело, что в идеологии git бранчи *могут быть* использованы достаточно вольно, и, на самом деле, такое «нетрадиционное» использование поощряется всей практикой работы. Поэтому и возникает потребность в определениях, несколько отличающихся от тех, которые, как Вы думаете, «отлиты в граните».

_Высечены_ в граните. Я не против новых определений, когда они нужны. Но когда _существующие_ термины переопределяются в стиле Шалтая-Болтая, это вызывает раздражение.

> Какого еще rebase? Напомню:

Да, я перепутал нумерацию со своей первой последовательностью, там в этой позиции стоял как раз ребэйз.

Ну а то, что касается «вдумчивого сравнения». В простейших случаях действительно можно обойтись «текстовым редактором с диффами» и устными переговорами. Но, честно, опыт показывает, что отсматривание коммитов удобнее проводить в комплексном наборе инструментов, включающем в себя какую-нибудь специализированную гляделку, средство аннотирования изменений, чата, прогона тестов и так далее. VCS и её возможности тут, конечно, важны, но явно не приоритетны. По правде говоря, полностью удобного инструмента для решения этой задачи я не видел.

в ,v-файлах есть метки бранчей.

Есть. Но они не порождают новых версий (файлов). И, соответственно, на одну версию может быть «навешано» произвольное количество бранчпойнтов. В отличие от SVN'а, где ревизия из которой порождён бранч не является частью бранча.

Git рассматривает так любой коммит (и Mercurial тоже).

Э-э-э, не, породить бранч из любого выбранного места в истории - свойство, наверное, любой VCS, поддерживающей бранчи :) Вопрос только в том, как технологически порождается бранч. Моё исходное утверждение было, что в CVS и SVN имеются различия в устройстве, достаточные для того, чтобы взаимно-однозначное отображение дерева ревизий CVS и SVN было в общем случае невозможно. А Вы говорите, у них консенсус относительно определения бранча...

«отлиты в граните».

«_Высечены_ в граните»

Хех, это новый юридический термин, Вы что, не в курсе последних новостей? :)

> «отлиты в граните»

Кстати, сын, увлекающийся геологией, сказал мне, что, в принципе, можно и «в граните отлить». Правда плавить для этого надо не гранит, после застывания там другая метаморфическая порода получается, а ту породу, которая при соответствующем давлении и температурном режиме даёт в итоге как раз гранит. И породы называл, да я их позабыл :)

У меня вопрос к пользователям git:

Имеется коммит, помеченый тэгом old-content. как мне быстро посмотреть содержимое файла chapter1.tex в ревизии, которая идет после помеченой. В hg это делается так:

hg tags

tip 223:d0b45af68b19
old-content 115:42025376dc1e

hg cat -r 116 chapter1.tex

...

Беглое чтение справки не помогло.

Давно программирую на Питоне, но выбрал когда-то git и два года им пользовался.

Со временем перевёл все проекты на Mercurial, так как он снял много мелких вопросов, включая: совместимость, кроссплатформенность, инкрементальный бэкап базы, упрощённое использование.

Ну, с моей точки зрения термин «ревизия, идущая после помеченной» недоопределён. По всей видимости, в задаче требуется показать файл по определённому пути в коммит(ах), одним из родителей котор(ых) является помеченный коммит. Замечу, что в такой постановке у задачи может быть несколько решений, и в гит, и, насколько я знаю, в mercurial. Причём, по крайней мере в гит (но, видимо, и в mercurial тоже), коммит «с ревизией 116» (то есть, сгенерированный по времени после 115) может не являться решением задачи.

Показ любого файла (ну и вообще любого объекта в базе) делается при помощи команды git show. В нашем случае это

git show <committish>:chapter1.tex

Теперь вопрос заключается в том, чтобы определить, какие коммиты подходят для решения нашей задачи. Можно, конечно, глазами посмотреть это в gitk или на «список коммитов после тэга» командой git log, что-то наподобие:

git log --reverse --decorate --pretty=oneline old-content^..

(примерно это и делалось в hg'шном вызове hg tags, только здесь немножко подробнее и вывод отсортирован от более ранних коммитов к более поздним. Так, команда

git log --reverse --decorate --pretty=oneline 0.9.4^..

в моём репозитории eee-control даёт вот такой вывод: http://pastebin.ca/1731409

Но, разумеется, «именно этого они от нас и ждут». Более правильно и индустриально - написать ўанлайнер, который покажет по очереди файл chapter1.tex из всех подходящих под условие задачи коммитов:

for c in $(git rev-list --all --children old-content^..) | tail -1 | cut -d ' ' -f 2-); do git show $c:chapter1.tex; done

Очень рад за Вас. Скажите, какую цель преследует Ваше появление здесь?

понятно, что редактором... хотя может и можно привинтить к виму что-то вроде «вставить с таким-то относительным отступом», надо будет подумать на досуге...