LINUX.ORG.RU

git-1.6.6 вышел

 , , , , ,


0

0

В рассылке fa.linux.kernel анонсирован выход новой версии распределенной системы контроля версий Git.

Среди изменений:

  • Улучшения в утилитах GUI (git gui и gitk): добавлена поддержка тем tk 8.5, исправлены мелкие ошибки;
  • Улучшена скорость работы git-fetch через HTTP: полный обход коммитов заменен более интеллектуальным алгоритмом;
  • К команде git-fetch добавлена опции --all и --multiple, позволяющие забирать коммиты сразу из нескольких удаленных репозиториев;
  • Уменьшено использование памяти при выполнении команды «git diff -B»;
  • «git instaweb» теперь поддерживает работу с mod_cgid;
  • imap-send теперь может быть собран в окружении mingw32;
  • В git-svn добавлена поддержка пересоздания пустых директорий (git отслеживает только файлы, потому при импорте SVN-репозитория вставала проблема пустых директорий). Кроме этого улучшена обработка слияний в SVN;
  • «gitweb» теперь имеет опциональную поддержку инкрементального вывода «blame» (для работы опции нужна поддержка JavaScript в браузере клиента);
  • и многое другое (см. changelog)

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

Скачать

>>> Подробности

★★★★★

Проверено: boombick ()

Ответ на: комментарий от xorik

> Поясняю:Ты хочешь изменить старый коммит. Лишние действия в hg: конвертировать в mq, pop, изменяешь, push, превращаешь в обычные коммиты.

hg qimport -r

<меняем что-то>

hg qref

hg qfin # необязательный шаг

теперь сделай это в гите и удивись :)

Давай последовательность команд.

tailgunner ★★★★★
()
Ответ на: комментарий от xorik

> только ты не сказал что надо изменять патчи, а не исходники

Чтооо? Изменять надо именно исходники, и эти изменения становятся частью патча при qref.

Так что гони список команд git.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

может быть
git rebase -i <commit>
изменяешь
git commit --amend
git rebase --continue

Если последний коммит, то достаточно одной строки:
git commit --amend

xorik ★★★★★
()
Ответ на: комментарий от xorik

Эээ... то есть для того, чтобы изменить не-последний коммит, нужно делать rebase? Это именно то, что должно было нас удивить? %)

tailgunner ★★★★★
()
Ответ на: комментарий от AlexM

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

Ну да, так и работаю с MQ.

растащить пачку образовавшихся изменений на логически цельные, правильно отсортированные коммиты

Кстати, как это делается в git? Я иногда просто открываю патчи в текстовом редакторе и таскаю изменения туда-сюда как текст.

Хотя, конечно, ничего не мешает сбросить всё в текстовые файлы и оперировать уже ими, но, как правило, это не нужно.

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

Поэтому мне собственно и интересно, а MQ - это обязательное условие для подобного воркфлоу или, всё-таки, и в pure hg подобное делается удобно?

Во-первых, MQ — это стандартное расширение, входящее в поставку Mercurial.

Во-вторых, почему это неудобно? Это не троллинг, а попытка выяснить, какие есть более удобные штуки, чем те, которыми я сейчас пользуюсь.

pitekantrop ★★★
()
Ответ на: комментарий от xorik

> З.Ы. хватит спорить, используйте что для вас удобнее

Не знаю, кто как, а я пытаюсь узнать, может есть способ сделать свою работу ещё более удобной.

pitekantrop ★★★
()
Ответ на: комментарий от AlexM

> git add --interactive - выбрать из списка изменений в рабочем дереве те, которые будут закоммитаны следующей командой git commit. Можно выбирать как целиком изменённые файлы, так и отдельные изменённые строчки в файлах, при этом содержимое рабочего дерева не меняется, меняется только индекс.

Где и как можно выбрать отдельные строчки?

git commit --amend - исправить предыдущий коммит изменениями, помеченными для коммита.

Я могу пометить для коммита не весь файл, а отдельные изменения в нём?

pitekantrop ★★★
()
Ответ на: комментарий от xorik

> git rebase -i <commit>

hg qpop <patch>

изменяешь

git commit --amend

hg qrefresh

git rebase --continue

hg qpush --all

pitekantrop ★★★
()
Ответ на: комментарий от xorik

вот типа так, если D это ветвь, а E это голова текущая, которую можно сделать ветвью

A - B  - C - D
     \ E

xorik ★★★★★
()
Ответ на: комментарий от tailgunner

> «Зелен виноград» (c)

Тов. тэйлганнер, Вы чо такой агрессивный? Повторяю, для желающих есть stgit, который сделан «по образу и подобию» MQ. Но, честно, сходу я не увидел в нём каких-то прелестей в сравнении со своим обычным воркфлоу. Но если Вы мне окажете любезность и покажете на примерах, что я получу «дополнительно», если буду оперировать не набором коммитов с git add -i, а набором патчей, я, может быть, попробую его ещё раз «и возлюблю».

«Влегкую» %)

А что, нет? Коммиты, что россыпью, что последовательностями, «копируются», поменять нужное в процессе легко, простые цепочки переносятся автоматом через git rebase -i, в общем, да, «влёгкую».

И вроде бы git cherry-pick работает путем генерации и наложения патчей? %)

А не побоку ли, как оно внутри устроено, интересен лишь пользовательский интерфейс. С точки зрения пользователя процедура выглядит как по возможности автоматическое покоммитное копирование изменений из ветки А в ветку Б.

Да что вы доколебались до факта, что MQ - плагин?

Вероятно, я выразил свою мысль недостаточно ясно. Мне по-прежнему кажется, что имеющийся в гите способ решить задачу (или задачи данного класса) - вполне достаточен и использование сторонних средств, типа stgit, представляется излишним. В случае конкретно hg есть, я слышал, нарекания на совместимость различных расширений между собой. И вообще сам факт популярности MQ может свидетельствовать лишь о том, что в чистом hg подобные задачи решать неудобно. Но я с интересом выслушаю, как дело обстоит «в реальности». Ну, или, по крайней мере, представляется Вам как реальность.

AlexM ★★★★★
()
Ответ на: комментарий от tailgunner

> Давай последовательность команд.

для случая, когда имеется последовательность коммитов A->B->C->D в активной ветке BR1 и требуется коммит B заменить коммитом Bch нужно сделать следующее:

1. git checkout -b tmp B — создаём временную ветку tmp, указывающую на коммит B, переключаем рабочее дерево на этот коммит.

2. <вносим изменения в рабочее дерево>

3. git add -i / git commit --amend — коммитаем требуемые изменения, формируя в итоге следующий набор коммитов:

A -> B -> C -> D (BR1)
\-> Bch (tmp)

4. git checkout BR1 — переключаемся обратно на BR1 (коммит D)

5. git rebase -i tmp — переназначаем предка коммита C (и, по, цепочке, D), формируя следующий набор коммитов:

A -> B -> C -> D
\-> Bch -> C' -> D' (BR1)

Коммиты B, C и D в этом случае оказываются «неиспользуемыми» (разумеется, если они не нужны более никому), они не показываются «по умолчанию», но доступны через git reflog и сохраняются в гитовой базе до следующего запуска gc.

6. git branch -D tmp — удаляем более не используемый бранч.

Как видно моё достаточно подробное и «лишённое магии» объяснение не сильно длиннее, чем цепочка для hg. В случае, когда требуется произвести что-то подобное для нескольких коммитов, по прикидкам, разница будет ещё менее существенна, т.к. основная тяжесть задачи смещается в сторону (повтора) шагов 2 и 3, возможно, с использованием cherry-pick'ов.

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

> Тов. тэйлганнер, Вы чо такой агрессивный?

/me .oO( Господи, почему все эти злобные людишки считают меня, такого белого и пушистого, агрессивным? )

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

Насколько я помню историю, и MQ, и StGIT - это потомки quilt. А ты не «не видишь прелестей» потому, что нужная функциональность уже вызывается как подкоманды git. Но, IIRC, изначально, году в 2005-м, ее просто не было - а MQ уже был, так что Git просто молча интегрировал MQ :)

И вроде бы git cherry-pick работает путем генерации и наложения патчей? %)

А не побоку ли, как оно внутри устроено

Не всегда, но в любом случае - не пользователям git cherry-pick неуважительно отзываться о патчах :)

Да что вы доколебались до факта, что MQ - плагин?

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

Блин. MQ - это _не_ стороннее средство, оно входит в стандартный пакет mercurial, просто исходники лежат не в merurial/, а в hgext (потому что Мэтт считает, что в core VCS не должно быть средств редактирования истории).

Но я с интересом выслушаю, как дело обстоит «в реальности». Ну, или, по крайней мере, представляется Вам как реальность.

В моем представлении о реальности MQ используют все, и он описан в Mercurial Book.

tailgunner ★★★★★
()
Ответ на: комментарий от AlexM

> И вообще сам факт популярности MQ может свидетельствовать лишь о том, что в чистом hg подобные задачи решать неудобно.

Что ещё за «чистый hg»? MQ входит в стандартную поставку. Так что во-первых

А не побоку ли, как оно внутри устроено, интересен лишь пользовательский интерфейс.

А во-вторых, то, что MQ — расширение, говорит о хорошей модульной архитектуре Mercurial.

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

> Я иногда просто открываю патчи в текстовом редакторе и таскаю изменения туда-сюда как текст.

Ну, примерно такой режим есть в git add --interactive (правда, только консольном). Аналогичный режим «на уровне коммитов» есть для git rebase (и тоже --interactive :) )

MQ интегрирован с Mercurial таким образом, что с накладываемыми патчами работаешь как с обычными коммитами и можешь не принимать во внимание их текстовую сущность.

Хых, ну мне, скорее, не понравилась идея обязательно вытаскивать в текст то, что можно сделать на уровне коммита (с атрибутами и прочим)

Во-вторых, почему это неудобно? Это не троллинг, а попытка выяснить, какие есть более удобные штуки, чем те, которыми я сейчас пользуюсь.

Ну, я уже ответил тов. тэйлганнеру, что мне представляется излишним использование чего-то поверх plain git в этом случае. Хотя, повторюсь, есть и развивается stgit, правда, у меня он сразу как-то не прижился. Может быть, имеет смысл посмотреть на него снова.

AlexM ★★★★★
()
Ответ на: комментарий от pitekantrop

> Где и как можно выбрать отдельные строчки?

Ну, э-э-э, там :) Или в консольном выбрать режим 'e' и «просто отредактировать патч в $GIT_EDITOR» или в git gui путём кликанья правой кнопкой на строчку изменения и выборе пункта «Включить данную строчку в коммит»

Я могу пометить для коммита не весь файл, а отдельные изменения в нём?

Да, разумеется, см. выше.

AlexM ★★★★★
()
Ответ на: комментарий от pitekantrop

> Кстати вопрос, что будет в git, если я поменял коммит в середине, а следующие коммиты конфликтуют с этим изменением?

Ну, git rebase отругается, предложит разрезолвить конфликт и продолжить git rebase --continue

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

> ну мне, скорее, не понравилась идея обязательно вытаскивать в текст то, что можно сделать на уровне коммита (с атрибутами и прочим)

Ы? Там есть все атрибуты - от автора до атрибутов файла и информации о переименовании. Впрочем, rebase в Mercurial тоже есть.

мне представляется излишним использование чего-то поверх plain git в этом случае

Ты с какой версии Git используешь? Помнишь ли его начало, разговоры о plumbing и porcelain? Вот plumbing можно было бы назвать plain git, но plumbing давно уже нет. Plain Git не существует - просто по маркетинговым или иным соображениям там не используется термин «plugin» :)

tailgunner ★★★★★
()
Ответ на: комментарий от AlexM

> Ну, git rebase отругается, предложит разрезолвить конфликт и продолжить git rebase --continue

Гм, xorik сказал, что будет новая голова: http://www.linux.org.ru/jump-message.jsp?msgid=4367549&cid=4374058

А я это так понял, что git commit --amend всегда создаёт новую голову. Так всё-таки нет?

pitekantrop ★★★
()
Ответ на: комментарий от tailgunner

> /me .oO( Господи, почему все эти злобные людишки считают меня, такого белого и пушистого, агрессивным? )

Э-э-э, по поведению? :)

Но, IIRC, изначально, году в 2005-м, ее просто не было - а MQ уже был, так что Git просто молча интегрировал MQ :)

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

не пользователям git cherry-pick неуважительно отзываться о патчах :)

Я не «неуважительно отзываюсь о патчах», а недоумеваю, зачем использовать их енд-лузеру, когда на это нет особых причин. Редактирование «настоящего патча», даже используя «нормальные редакторы», типа емакса в соответствующем режиме, - дело довольно хлопотное, лишний символ воткнёшь по недосмотру - и оппа... А /usr/bin/patch ещё и громко возмущается, если заявленное количество строк в каком-либо чанке не соответствует актуальному, у парсера башню рвёт (git add -i в этом месте гораздо терпимее).

Насчёт «расширений vs builtin». Предлагаю замять именно эту тему и в дальнейшем сравнивать непосредственно MQ (если он является штатным средством решения задачи) со штатным git commit --amend & Co, описанными выше. При этом памятуя о том, что для эстетов есть stgit :)

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

>> Но, IIRC, изначально, году в 2005-м, ее просто не было - а MQ уже был, так что Git просто молча интегрировал MQ :)

Какой-то завистью первородства попахивает,

Mercurial старше, чему завидовать? :)

Кого интересует, что было в 2005 году

Знание истории помогает понять решения, приняты при проектировании.

Я не «неуважительно отзываюсь о патчах», а недоумеваю, зачем использовать их енд-лузеру

А он их и не обязан использовать. Может, при желании, но не обязан.

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

За 4+ года работы с Mercurial сам патч (hunks) я редактировал меньше десятка раз.

Насчёт «расширений vs builtin». Предлагаю замять именно эту тему

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

сравнивать непосредственно MQ (если он является штатным средством решения задачи) со штатным git commit --amend & Co, описанными выше

Легко: «hg qref» значительно короче, чем git commit --amend (ага, я знаю об алиасах).

tailgunner ★★★★★
()
Ответ на: комментарий от AlexM

Вызывает интерес вот ещё какой разрез...

Допустим, я работаю над какой-то функциональностью. В конце концов у меня получается N ченджсетов(коммитов, патчей), которые я отдаю другому разработчику для ревью. Он в свою очередь вносит в каждый мой ченждсет свои корректировки и отсылает их мне. После этого я смотрю, на его корректировки и мерджу их в соответствующие свои ченджсеты. Затем я наконец отдаю ченджсеты в основной репозитарий.

Насколько удобно реализовать этот сценарий в git?

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

> Насколько удобно реализовать этот сценарий в git?

А в Mercurial? Кроме pbranch и очевидного варианта с обменом патчами.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Легко: «hg qref» значительно короче, чем git commit --amend (ага, я знаю об алиасах).

Настоящие пацаны меряются, у кого длиннее.

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

pitekantrop ★★★
()
Ответ на: комментарий от tailgunner

> А в Mercurial? Кроме pbranch и очевидного варианта с обменом патчами.

Сначала делали так: командой hg qinit -c делали репозитарий в .hg/patches/ (это где патчи хранятся). Потом один делал bundle с патчами из этого репозитария и отсылал на ревью. Второй разработчик для патча feature-1.patch делал патч feature-1-tofold.patch с изменением к этому патчу. Потом эти патчи коммитились в репозитарий для патчей и новый bundle пересылался обратно. Потом первый разработчик смотрел на изменения и командой hg qfold мержил их в соответсвующие патчи. Потом, как обычно, hg qfinish --all и hg push.

А потом Пео сказал, что это неудобно, и написал pbranch.

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

У нас с Вами намечается терминологическая путаница :)

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

головой (HEAD) в терминологии git предлагается называть «указатель» на коммит в некоторой последовательности. Обычно HEAD указывает на текущий активный бранч, который в свою очередь, указывает на конкретный commit-ID, но можно выделить и произвольный коммит (git checkout <commit-ref>). Посмотреть содержимое HEAD можно в файлике .git/HEAD, значение указателей бранчей хранятся в .git/refs/ и, если есть, .git/packed-refs.

git commit создаёт новый коммит, указывая в качестве parent текущий выделенный коммит, после чего смещает на вновь созданный коммит указатель branch или HEAD, в зависимости от того, что написано в .git/HEAD в момент коммита.

git commit --amend создаёт новый коммит на базе существующего и опять-таки, передвигает указатель HEAD или branch на вновь созданный коммит.

Поэтому отвечая на Ваш вопрос: да, rebase всегда создаёт новую цепочку коммитов (т.к. меняется parent). Если в процессе rebase происходит конфликт, то после его разрешения rebase продолжит создавать коммиты в новой цепочке (см. C', D' в моём примере выше).

AlexM ★★★★★
()
Ответ на: комментарий от pitekantrop

> bundle с патчами из этого репозитария и отсылал на ревью. Второй разработчик для патча feature-1.patch делал патч feature-1-tofold.patch с изменением к этому патчу

АдЪ

А потом Пео сказал, что это неудобно, и написал pbranch.

И вы стали им пользоваться?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Даже в полном варианте это короче git commit --amend.

В правильно настроенном баше длина часто используемых команд роли не играет. ;)

Печатаешь несколько первых букв, а потом за пару нажатий PgUp/PgDn находишь нужную.

pitekantrop ★★★
()
Ответ на: комментарий от tailgunner

> И вы стали им пользоваться?

Видимо, придётся. :) Пео старый вариант с MQ и xyz-tofold.patch-ами использовать больше не хочет. :)

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

> Насколько удобно реализовать этот сценарий в git?

Слово называется gerrit :) В смысле, у гугла в андроиде на этот повод навёрнута мощная обвязка с распределением ролей, code review'ингом и прочими радостями. Унутре, помимо кучи остального говна, свой git-сервер, написанный на яве (прямо таки вижу, как в этом месте содрогаются от отвращения заядлые змееловы :) , «испытано на себе») Но, вроде, работает.

Если же не париться «индустриальным» решением вопроса (а gerrit и аналоги - это именно индустриальное решение для teamwork), то выглядит это так:

1. вначале вы помечаете требуемую цепочку изменений, как ветку (повторюсь, в терминах git'а ветки - это именованные указатели на коммиты). Назовём эту ветку the_feature

2. Далее Вы push'ите эту ветку товарищу (например, по протоколу git+ssh://), или от fetch'ит у вас эту ветку (по любому из доступных протоколов, в том числе, анонимных).

3. он вносит в неё свои изменения (см. выше про коммит Bch) и сообщает Вам о том, что неплохо бы провернуть обратную процедуру.

4. Вы fetch'ите его ветку (в общем случае она теперь указывает на другую цепочку), у Вас, появляется remote ветка friend/the_feature (или с любым другим удобным для Вас именем, это настраивается)

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

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

7. Вы пушите ветку the_feature на «центральный сервер». Если параллельно там ведутся ещё какие-то работы, то the_feature в подходящий момент (или моменты, например, непосредственно по ходу разработки) merge'ится или rebase'ится в Вашем репозитории относительно «центральной» линии разработки.

Ну, как-то так.

Но, кстати, системы для code review - это хорошо :) Кстати, reviewboard уехал хоститься с svn на git :) Так что, ждём описанной выше схемы, обёрнутой в красивый веб-интерфейс, написанный на православном джанго ;)

AlexM ★★★★★
()
Ответ на: комментарий от tailgunner

>> Какой-то завистью первородства попахивает,

Mercurial старше, чему завидовать? :)

Именно. Классический случай, когда старший брат завидует более успешному младшему. Например, как в случае каталонцев и кастильцев. Есть и гораздо более актуальные для нас примеры, но не буду упоминать их, чтобы не спровоцировать х.......ч :)

вместо общепринятой.

Общепринятой кем. Перечислите всех поимённо :)

ага, я знаю об алиасах

Что-что, а гитовые команды въедаются в пальцы почище емаксовых шорткатов или vim'овых команд :)

AlexM ★★★★★
()
Ответ на: комментарий от tailgunner

Так, с беспочвенными ругательствами - в са^H^H на свежий воздух, отдохнуть, поправить нервы. Как задача была сформулирована, так, с точностью до пунктов и решил ее.

AlexM ★★★★★
()
Ответ на: комментарий от pitekantrop

> Второй разработчик для патча feature-1.patch делал патч feature-1-tofold.patch с изменением к этому патчу.

А если надо поменять их количество, например, из одного сделать два?

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

>> вместо общепринятой.

Общепринятой кем. Перечислите всех поимённо :)

CVS, SVN, OpenCM, Mercurial, Bazaar-NG. Никто из них не вводил собственной терминологии :) Даже BK, насколько я могу судить.

tailgunner ★★★★★
()
Ответ на: комментарий от AlexM

> Так, с беспочвенными ругательствами - в са^H^H на свежий воздух, отдохнуть, поправить нервы.

Эээ... «адЪ» - это ругательство? Это характеристика юзабельности (ровно такая же, как и для аналогичного решения в mercurial, кстати). Кому еще надо на свежий воздух %)

Как задача была сформулирована, так, с точностью до пунктов и решил ее.

К решению претензий нет. Оно будет работать - в Аду им будут карать за мелкие программистские проступки :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> CVS, SVN

Так, или я не понимаю, о какой именно терминологии Вы ведёте речь, или Вы пытаетесь меня обмануть. Я довольно неплохо представляю себе внутреннее устройство ,v и соответствующих элементов конструкции в SVN, и могу сказать, что в части бранчей и др. в этих двух системах терминология явно «плывёт», так что ни о какой общепринятости говорить не приходится. Как минимум, для этих двоих. То, что mercurial позиционируется как «svn для (про)двинутых», как в своё время svn позиционировался, как cvs на стероидах, - это я тоже слышал, неудивительно, что в hg стараются быть максимально понятными.

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

>> CVS, SVN

Так, или я не понимаю, о какой именно терминологии Вы ведёте речь

О бранчах. Других примеров я не помню - я давно уже довольный пользователь Mercurial.

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

Причем тут внутренности ,v? Речь о том, что определение «бранч == движущийся указатель на коммит» - это изобретение Git. В Mercurial хоть догадались назвать это bookmark.

То, что mercurial позиционируется как «svn для (про)двинутых», как в своё время svn позиционировался, как cvs на стероидах, - это я тоже слышал

Странно, я этого не слышал. О том. что Mercurial - это «Git с человеческим лицом», я слышал хотя бы краем уха.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> «адЪ» - это ругательство?

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

AlexM ★★★★★
()
Ответ на: комментарий от tailgunner

> О бранчах.

HEAD и бранчи в CVS и SVN значат разные вещи. В терминах CVS бранч - это, прежде всего, *точка* ветвления, не обязательно влекущая за собой возникновение новых версий. В терминах SVN бранч - это *копия*, сделанная в какой-то момент времени и пошедшая своим путём. В этом контексте GIT'овское бранчевание по семантике ближе к CVS'ному. Впрочем, SVN вообще очень вольно толковал многие из существовавших до него понятий, - и ничего, прижился.

я давно уже довольный пользователь Mercurial.

... и поэтому отмечаюсь в каждом треде про Git. Ну, да, чо, счастливо женатому мужику больше делать нечего, кроме как дискутировать о посторонних бабах ;)

О том. что Mercurial - это «Git с человеческим лицом», я слышал хотя бы краем уха.

«Странные люди». Как работа над ошибками может быть раньше ошибок :)

В общем, кажется, дискуссия выродилась ;) Заранее прошу прощения, если задел Вас сильнее, чем самую малость, «товарищеским тычком под ребра». На pbranch посмотрю, если он действительно привносит в обсуждавшийся процесс какие-то существенные улучшения.

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

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

Обосновали эту характеристику описания процедур, приведенные pitekantrop для Mercurial и тобой для Git (шаги 5 и 6 - это просто песня).

Даже если некоторые из этих характеристик маскируются под похвалу.

Под похвалу я ничего не маскировал. Обе процедуры - уродство.

HEAD и бранчи в CVS и SVN значат разные вещи. В терминах CVS бранч - это, прежде всего, *точка* ветвления, не обязательно влекущая за собой возникновение новых версий.

И в CVS, и в SVN, и везде, бранч - это именованный набор изменений (я бы сказал «changeset'ов», но в CVS их нет). И только в Git - это указатель на узел графа.

я давно уже довольный пользователь Mercurial.

... и поэтому отмечаюсь в каждом треде про Git

Я участвую во всех (или почти всех) тредах о VCS. Мне это просто интересно.

Ну, да, чо, счастливо женатому мужику больше делать нечего, кроме как дискутировать о посторонних бабах ;)

Хм, сравнивать VCS с женщинами... не со слесарным инструментом или, например, машинами, а именно с женщинами :D

О том. что Mercurial - это «Git с человеческим лицом», я слышал хотя бы краем уха.

«Странные люди». Как работа над ошибками может быть раньше ошибок :)

Во-первых, и Mercurial, и Git - вторичные системы (потомки OpenCM и Monotone); во-вторых, «работа над ошибками» проведена уже очень давно - существуют десятки VCS, и требования к интерфейсу давно выработаны. Просто аффтары Git решили забить на это (злые языки говорят, что это из-за личной вендетты Линуса против CVS :))

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> АдЪ

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

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

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

pitekantrop ★★★
()
Ответ на: комментарий от AlexM

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

Пео пишет, что его вдохновили bzr-loom и особенно topgit. Так что тебе, возможно, лучше посмотреть на последний.

pitekantrop ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.