Вышел Mercurial 1.9

pull в hg по-умолчанию работает как fetch в git'е. Это его естественное и интуитивное понятное поведение. То что pull после собственно pull'а еще должен делать merge это уникальное «изобретение» разработчиков git'а.

> Например, по краткому описанию к git reset можно сделать вывод, что этой командой можно сбросить изменения _только_ _всего_ репозитория.

man git-reset

NAME

git-reset - Reset current HEAD to the specified state

SYNOPSIS

git reset [-q] [<commit>] [--] <paths>...

git reset --patch [<commit>] [--] [<paths>...]

git reset [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>]

Аргумент paths в первых двух вариантах команды (причём в первом он обязательный) не случаен.

DESCRIPTION

In the first and second form, copy entries from <commit> to the index. In the third form, set the current branch head (HEAD) to <commit>, optionally modifying index and working tree to match.

И так далее. Изменение индекса — ни коим образом не сброс всего репозитория. branch head тоже всего лишь branch head, а не весь репозиторий.

Если в git есть разделение на низкоуровневые команды и высокоуровневые команды, то почему это не обозначено в мане?

man gitcore-tutorial

The core git is often called «plumbing», with the prettier user interfaces on top of it called «porcelain». You may not want to use the plumbing directly very often, but it can be good to know what the plumbing does for when the porcelain isnt flushing.

Back when this document was originally written, many porcelain commands were shell scripts. For simplicity, it still uses them as examples to illustrate how plumbing is fit together to form the porcelain commands. The source tree includes some of these scripts in contrib/examples/ for reference. Although these are not implemented as shell scripts anymore, the description of what the plumbing layer commands do is still valid.

Или претензия к тому, что в каждом мане не сказано, является описываемая команда plumbing или porcelain? Это разделение достаточно очевидно. К тому же, в манах к porcelain часто говорится, интерфейсом к каким командам они являются, а в манах к plumbing — какие высокоуровневые команды на них основаны.

> Это его естественное и интуитивное понятное поведение.

«Интуитивно понятный интерфейс», «интуитивно понятное поведение» в ИТ — маркетинговый bullshit и ничего более.

TFS - это много-много больше, чем просто VCS. Но даже в этой ипостаси умеет много-много больше, чем VSS.

> «Интуитивно понятный интерфейс», «интуитивно понятное поведение» в ИТ — маркетинговый bullshit и ничего более.

«Сколько тебе лет?» (с)

>мне вот интересно, был же биткипер, которым линус пользовался несколько лет, почему нельзя было просто всё скопировать, нафига было изобретать свое, которое только хуже ?

Ну как минимум с стороны Линуса это было бы свинство. Кроме того я думаю он делал как удобно ему.

> был же биткипер, которым линус пользовался несколько лет, почему нельзя было просто всё скопировать, нафига было изобретать свое, которое только хуже ?

Git на голову выше BK по концепции (хотя это и не заслуга Линуса); а UI можно было копировать откуда угодно, всё равно было бы лучше.

Прекрасно!

> Только это не гарантирует, что нет людей, которые работают с репозиториями по отдельности и не коммитят в метарепозиторий.

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

> Это его естественное и интуитивное понятное поведение.

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

это я знаю, но сам man git довольно неоднозначный

в hg это решается с помощью hg pull -u, а также с помощью настроек «черепахи», поэтому и команда одна и ненужного усложнения процесса нет

>man svk. Распределенный и простой в использовании, как SVN.

коссподя, выключите свет, эти маргиналы на свет ползут!

Если по простому использовать git, то он и есть простой.

Пожалуй единственный минус git это название его комманд. Многим нравится разное, и очень удобно когда это разное лишь внутри, а снаружи похожи - не приходиться тратить время на изучение. На практике приходиться работать со всем сразу - и тут гит отличился своей непохожестью, когда на его использование приходиться читать слишком много мана, не полагаясь на интуицию, основанную на предыдущем опыте. Тут Линус поступил просто по-свински - аля Микрософт - это некая притензия на мировое господство - человек подсевший на гит - с трудом воспринимает другие системы контроля версий, из-за того что команды другие. Да система просто великолепная по всем параметрам, но команды... когда приходиться клонировать из базаара, ртути, свна - гит выбивается - им неудобно пользоваться обыватели - хотя система просто великолепна.

вот именно, что «просто пользовать гит, потому что он простой» - был бы таким же как все - с такой же системой команд - на него намного быстрее перешли бы все - отказавшись от cvs и svn(а таких очень много), а продолжают пользовать их из-за того, что слишком большие энерго-затраты для переезда на гит, из-за его названий команд. ему просто необходима лайт-версия команд - тогда на него намного быстрее поползет народ.

Если «обыватели» не осилил man alias (не говоря о графическом клиенте к СКВ), может быть, ему стоит подумать о смене профессии на такую, где СКВ вообще не нужны? И где не нужно знание русского языка.

> коссподя, выключите свет, эти маргиналы на свет ползут!

Git-фанбои набигают в тред о Mercurial и еще ноют.

Hg-фаги могут набижать в тред о гите. Мы совсем не против.

> Hg-фаги могут набижать в тред о гите. Мы совсем не против.

Мы не будем ни спрашивать, ни ныть %)

Чего-то я вас не понял. всегда делаю git pull. В git pull входит git merge и git fetch. У вас что, бревно в глазу?

У вас что, бревно в глазу?

Ты как читаешь? Reset уже не раз повторил: «Две команды для двух действий — это слишком сложно для меня».

Зачем усложнять то, что можно сделать простым?

Зачем усложнять то, что можно сделать простым?

Это не вопрос простоты, это вопрос вкуса.

По мне, так hg pull/hg pull -u или git fetch/git pull совершенно одинаковы.

К этому можно добавить, что hg pull --rebase не работает из коробки.

По мне, так hg pull/hg pull -u или git fetch/git pull совершенно одинаковы.

hg pull -u не мержит, он делает update после пула, то есть в гитовской терминологии чекаут. Поэтому про ребейз вообще не в тему. Юникс вей же.

hg pull -u не мержит

Да это просто чертово откровение. Тогда получается, что cli hg запутанней гитовского (по части вытаскивания изменений). Мало того, что для частой операции нужно выполнять две команды, так еще присутствует асимметрия в виде hg pull --rebase, при подключении расширения.

ИМХО засунуть merge в pull - это верх запутанности.

засунуть merge в pull

Это было сделано по многочисленным заявкам пользователей.

Интересно, а пруфлинк есть?

пруфлинк

Что-то gmane у меня пока недоступен. Но как только, так сразу попытаюсь найти.

>> hg pull -u не мержит

Да это просто чертово откровение. Тогда получается, что cli hg запутанней гитовского (по части вытаскивания изменений). Мало того, что для частой операции нужно выполнять две команды

pull + merge - частая операция? O_o Хренасе у вас режим работы.

действие одно, а не два

Интересно, а пруфлинк есть?

Чорд, нашел доказательство обратного. Торвальдс, действительно инопланетянин.

В первых версиях гита был добавлен волшебный скрипт который через rsync вытаскивал объекты и тут же их мержил, при необходимости.

действие одно, а не два

1) Притащить удаленные изменения в локальную репу

2) Привести рабочую копию в соответствие с удаленными изменениями.

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

Чую, что это желание торвальдса, ибо сделать pull, а потом обнаружить, что твоим сорцам пришел трындец это верх маразма. rollback в git'е надеюсь есть ?

что твоим сорцам пришел трындец

Из чего это следует? Я даже не знаю такой vcs, которая бы затирала историю.

Ага, суть то одна, просто в пункте (2) после вытягивания изменений выполняются доп действия, причем разрушительные действия. Я думал, что там checkout выполняется, но если там делается merge, то это лютый песец.

Дело не в этом, merge корежит дерево ревизий, поэтому пользоваться им надо с умом, иначе репозиторий превратится в помойку.

Я вообще использую mq и стремлюсь к тому, чтобы история была плоской.

> Я даже не знаю такой vcs, которая бы затирала историю.

Я знаю две - Mercurial и Git :)

merge корежит дерево ревизий

поэтому пользоваться им надо с умом

иначе репозиторий превратится в помойку

Ты точно о hg говоришь, не об svn? Что предлагаешь делать в случае разошедшихся веток? Какие такие предосторожности надо соблюдать при слиянии?

Вообще очень странно, что пользователь DVCS осторожничает с естественной для них операцией.

Или это относилось только к гиту? Если да, то в этой части он также безопасен (если не применять особое ключ-фу).

> Вообще очень странно, что пользователь DVCS осторожничает с естественной для них операцией.

История должна быть чистой. Развесистый граф ревизий бесполезен для основной практической цели - поиска ошибок.

Что предлагаешь делать в случае разошедшихся веток? Какие такие предосторожности надо соблюдать при слиянии?

Зависит от того на сколько разошедшихся. Если это вообще уже разные мажорные версии одной софтины, то, очевидно, что в автоматическом режиме их сливать нельзя.

Какие такие предосторожности надо соблюдать при слиянии?

Количество слияний надо минимизировать и не делать их без толку.

Или это относилось только к гиту? Если да, то в этой части он также безопасен

В git'е нет mq, поэтому я не могу держать свою работу постоянно сверху дерева ревизий и откладывать merge то последнего момента, когда будет точно 100% все готово.

поэтому я не могу держать свою работу постоянно сверху дерева ревизий

man rebase, который, кстати, и в меркуриале есть.

Развесистый граф ревизий бесполезен для основной практической цели - поиска ошибок.

bisect, по-идее, должен быть веткобезразличным.

bisect, по-идее, должен быть веткобезразличным.

Хрен там. Это печально.

>> поэтому я не могу держать свою работу постоянно сверху дерева ревизий

man rebase

rebase обладает другими неудобствами.

rebase обладает другими неудобствами.

Согласен. Но, как правило, его хватает. Надо только помнить что история переписывается и следить чтоб она не попала на всеобщее обозрение.

>> rebase обладает другими неудобствами.

Согласен. Но, как правило, его хватает

Как правило, его не хватает. Собственно, его и не должно хватать - это не инструмент для разработки, а инструмент редактирования истории.

Как правило, его не хватает

Кому не хватает, тот ударяется во все тяжкие (stgit, guilt). Или просто пользуется ртутью.

А лично мне еще ни разу не приходилось жалеть об отсутствии mq-like управления патчами.

> Кому не хватает, тот ударяется во все тяжкие (stgit, guilt).

Неинтегрированность этих инструментов как бы намекает на то, в git-сообществе просто не рубят фишку :)

А лично мне еще ни разу не приходилось жалеть об отсутствии mq-like управления патчами.

А я просто не понимаю, как люди без mq живут. Более того, я убежден, что это вообще не жизнь %)