Здравствуйте, ·, Вы писали:
·>Собственно да, букмарки и создавались по образу и подобию веток гита. Но проблемы с ними есть. Скажем, управлять нельзя как они пуллятся. И опять — глобальные имена "Be aware that there is only one namespace for bookmarks — it is advised to prefix your local-only bookmarks to avoid conflicts with other users." ·>И т.к. это опциональная фича с боку... как они поддерживаются другими тулзами? CI сервера, IDE, и т.п.?
Зато применяются по делу, в отличие от git.
Смотри, в mercurial и именновые ветки и закладки (выбираешь в зависимости от своего вкуса) применяются исключительно для выделения долгоживующих сущностей. Т.е. если у тебя реально в репозитории намечаются две принципиально разные ветки (скорее всего созданные в самом начале истории), то надо применять что-то из этой области. Если же у тебя реально только одна ветка, которая периодически разделяется и сливается из-за синхронизации работы команды, то выделенные именные сущности просто не нужны.
В Git же приходится применять ветки не только для реальных выделенных сущностей, но но и для обслуживания ситуации синхронизации параллельной разработки в одной (смысловой) ветке.
_>>Ну собственно "фиксация" — это и есть существительное. ) Это я выше некорректно написал (там было правильнее написать "фиксировать"). Только его значение является совсем не синонимом слову ревизия, а обозначает событие. ) ·>Брр. Бардак, ибо lingvo говорит, что commit это глагол только.
Нуу такие вещи лучше тут смотреть: http://www.multitran.ru/c/m.exe?a=110&t=858983_1_2&sc=138
_>>Нельзя) Нет, ветвления не появится пока не породишь ещё одного потомка из этой точки (не важно с каким именем). А пока у тебя вышло просто переименование одной и той же ветки. ) ·>Будет ревизия, с новым уникальным id, так ведь? Значит уже история пошла врозь. ·>И что сбивает с толку, есть коммит, с датой, с автором... но никаких изменений, diff пустой!
Ммм, я что-то не понял. Вот смотри, у нас идёт цепочка ревизий, в которой используется некое имя ветки (Х). Потом мы с какого-то момента решили продолжать эту цепочку под новым именем (Y). Мы сообщаем об этом mercurial (командой branch, которая по сути ничего не делает в самом хранилище) и следующие ревизии в цепочке будет носить уже новое имя Y. При этом никаких реальных развилок не наблюдается — они появятся только если вернуться назад и добавить новых потомков (не важно под каким именем ветки) к точке развилки.
Ну и да, это бредовый способ использования именованных веток (т.к. собственно ветвления тут нет) и его никто не использует. Но если очень хочется (я правда так и не понял зачем оно тебе такое было надо), то технически возможно.
_>>Так в Mercurial checkout (он же update) работает с именем ревизии и это является как раз привычным путём в любом случае. Правда туда можно передавать различные "хоткеи" (именованные ветки — тогда подразумевается их tip, закладки, теги), но это уже добавлено поверх, для удобства. ·>В git тоже, всё так же. Правда работать с номерами ревизий — не гуманно, git освобождает от этой необходимости когда возможно. Все эти ветки, теги, символические ссылки и т.п. — чисто для удобства человеков, сам гит может обходиться исключительно sha1 (и это удобно, особенно когда пишешь какую-нибудь автоматизацию/скрипты/славароботам).
В том то и дело, что не так же. Нет в git нормальной работы на уровне чистых ревизий. Вот к примеру как мне узнать список всех "голов" в хранилище? Я уже молчу про то, что git-gc может самовольно удалять подобные данные. Нет, в git нельзя нормально работать без именованных веток, хотя внутри у него в базисе такая же основа как и у mercurial. Но не смогли...
_>>Первый раз про такое слышу. Использовать ветки для ситуации без ветвления. Это похоже только от убогости других инструментов git'a. ·>Ещё раз. Оно расходится _может_, но не обязательно что _будет_. Скажем, если мы зарелизили что-то и оно всё сразу суперски заработало с первого раза — релиз будет в точности равен тому что надевелопилось. А если мы сделали поверх релиза хотфикс(ы) — ветки разойдутся.
Ну и пускай расходятся просто так — в mercurial всё равно же не обязательны именованные ветки/закладки для этого. Собственно ситуация кратковременного ответвления идеальна для реализации через анонимные ветки.
А вот реальные именованные ветки/закладки есть смысл использовать при наличие логически выделенных веток разработки, а не для синхронизации работы или установки каких-то меток (для этого есть теги).
_>>Вот всё, что ты перечислил, можно применить к какой-то отдельной ревизии (соответственно для этого оптимальные теги). А вот куда применить понятие "процесс релиза" не ясно. ) ·>Эээ. Если эти теги работают так же (можно, например, туда хотфикс закоммитиь) и мержить туды-сюды... то наверное сгодятся. ·>Т.е. я пушу что-нибудь в "release", это подхватывает CI-сервер, билдит, запускает тесты, шлёт имейлы, строит release notes, etc...
Практически все главные команды mercurial работают с понятием "ревизия" (а не ветка/закладка/тег и т.п.). В качестве идентификатора ревизии можно передавать:
— её уникальный id (хеш)
— её локальный id (порядковый номер)
— имя ветки (тогда подразумевается ревизия с тегом tip в этой ветке)
— имя закладки (прямой указатель на некую ревизию)
— имя тега (прямой указатель на некую ревизию)
Так что всё работает везде одинаково)
·>Пусть другой граф, пороще, с расхождением, мержем и одной веткой: ·>
Ну так ты поясни что это. Я вот вижу некую ветку, которая разделяется и потом сливается. Это понятно и нормально. Потом я вижу некую метку "development" на последней ревизии ветки. Что она у тебя должна означать? )
_>>Единственная разница в том, что в Git нет адекватных инструментов для удобной работы с этим базисом — требуется введение дополнительных сущностей более высокого уровня (типа указателей на ветки, специальных команд для ветвления и т.п.). ·>Что ещё за указатели на ветки? Есть просто reference (ссылка) и всё. Сссылка с префиксом refs/heads/ является веткой, с префиксом refs/tags/ — тегом, с префиксом refs/remotes/ — ссылки из чужих репо, и т.п. Там же и stash, там же и notes и кастомные вещи, типа pull requests гитхаба. ·>Команды какие ещё? update-ref только, остальные (branch, tag, notes) просто надстройки — для удобства человеков только.
ОК, а если у нас репозитории ревизия на которую нет ссылок через ветки/теги, то как нам с ней работать? )
Здравствуйте, netch80, Вы писали:
N>Не терялась. Но и не сохранялась. История подобного рода может только создаваться в процессе чтения истории изменений. На уровне коммита есть только новое состояние двух объектов — исходных файлов. Само понимание того, что произошёл перенос кода, возникает на основании сравнения объектов — источников и объектов — приёмников и определяется долей неизменённого кода при этом переносе (точной границы не помню, навскидку это около 70%).
N>Да, я тоже хотел бы, как в darcs, алгебру изменений с возможностью логически определять каждое из них в стиле "переименование", "перенос", "форматирование" и т.п. — это очень облегчает мержинг. Но реально это не выжило ни в одной из современных массово используемых DVCS.
N>Сколько при этом меняется внутри того файла? Если, например, в среднем одна строчка из 10, в истории будет факт переименования с указанием типа "91% similarity".
ну вот реальный пример из последних.
дано: большой класс (файл).
хочу: сделать его parital (разбить на два файла), соответственно "половина" функционал пойдет в один файл, половина в другой. оба имени файла отличные от оригинального, название класса тоже изменилось, попутно что-то пофиксилось.
что скажет история git про эти два новых файла? как они будут связаны с оригиналом?
Здравствуйте, alex_public, Вы писали:
_>·>Собственно да, букмарки и создавались по образу и подобию веток гита. Но проблемы с ними есть. Скажем, управлять нельзя как они пуллятся. И опять — глобальные имена "Be aware that there is only one namespace for bookmarks — it is advised to prefix your local-only bookmarks to avoid conflicts with other users." _>·>И т.к. это опциональная фича с боку... как они поддерживаются другими тулзами? CI сервера, IDE, и т.п.? _>Зато применяются по делу, в отличие от git. _>Смотри, в mercurial и именновые ветки и закладки (выбираешь в зависимости от своего вкуса) применяются исключительно для выделения долгоживующих сущностей. Т.е. если у тебя реально в репозитории намечаются две принципиально разные ветки (скорее всего созданные в самом начале истории), то надо применять что-то из этой области. Если же у тебя реально только одна ветка, которая периодически разделяется и сливается из-за синхронизации работы команды, то выделенные именные сущности просто не нужны.
Собственно по-моему это и есть философское отличие. В hg ты должен заранее решить что и как ты делаешь, что у тебя намечается и в зависимости от этого выбирать какой-то из механизмов, если ты принял неверное решение — исправить ситуацию довольно геморно. В git принципиальной разницы нет. Сделай как-нибудь что-нибудь как кажется правильным на текущий момент, а потом, если что, поменяешь как надо, когда будешь точно знать что тебе надо.
_>В Git же приходится применять ветки не только для реальных выделенных сущностей, но но и для обслуживания ситуации синхронизации параллельной разработки в одной (смысловой) ветке.
Ты так говоришь, как будто это что-то плохое. В стандартном случае у тебя после clone будет две ветки — master — твоя работа и origin/master — ветка оригинального репозитория. Ты сразу можешь точно видеть где твоё, а что идёт от других.
_>>>Нельзя) Нет, ветвления не появится пока не породишь ещё одного потомка из этой точки (не важно с каким именем). А пока у тебя вышло просто переименование одной и той же ветки. ) _>·>Будет ревизия, с новым уникальным id, так ведь? Значит уже история пошла врозь. _>·>И что сбивает с толку, есть коммит, с датой, с автором... но никаких изменений, diff пустой! _>Ммм, я что-то не понял. Вот смотри, у нас идёт цепочка ревизий, в которой используется некое имя ветки (Х). Потом мы с какого-то момента решили продолжать эту цепочку под новым именем (Y). Мы сообщаем об этом mercurial (командой branch, которая по сути ничего не делает в самом хранилище) и следующие ревизии в цепочке будет носить уже новое имя Y. При этом никаких реальных развилок не наблюдается — они появятся только если вернуться назад и добавить новых потомков (не важно под каким именем ветки) к точке развилки.
Да, верно. Чтобы появилось имя ветки надо сделать коммит, даже если содержимое X и Y идентично (тот же snapshot), их sha1 будет разный.
Т.е. если строгаю я всё в default-ветке, потом создаю release_candidate, и продолжу строгать default — появится расхождение графа ревизий. Это алогично, ведь по факту, с т.з. моих рабочих файлов — никаких расхождений нет, история изменений working copy — линейная. release_candidate не разхождение ревизий, а просто left behind ветка, которую можно fast forward.
Расхождение должно появиться только в том случае, если я внёс изменение и в release_candidate, и в default, т.е. появилась ревизия с двумя детьми. А что собственно значит появилось расхождение — это значит, что появилась "альтернативная история", которую можно 3-way мержить.
_>Ну и да, это бредовый способ использования именованных веток (т.к. собственно ветвления тут нет) и его никто не использует. Но если очень хочется (я правда так и не понял зачем оно тебе такое было надо), то технически возможно.
Да, закладки — как возможное решение. Остаётся вопрос — накой нужны ветки. И почему "это" называется "веткой" в hg.
_>·>В git тоже, всё так же. Правда работать с номерами ревизий — не гуманно, git освобождает от этой необходимости когда возможно. Все эти ветки, теги, символические ссылки и т.п. — чисто для удобства человеков, сам гит может обходиться исключительно sha1 (и это удобно, особенно когда пишешь какую-нибудь автоматизацию/скрипты/славароботам). _>В том то и дело, что не так же. Нет в git нормальной работы на уровне чистых ревизий. Вот к примеру как мне узнать список всех "голов" в хранилище? Я уже молчу про то, что git-gc может самовольно удалять подобные данные. Нет, в git нельзя нормально работать без именованных веток, хотя внутри у него в базисе такая же основа как и у mercurial. Но не смогли...
Голов слишком много, их можно найти через "fsck", или через "reflog". Например, когда правишь коммит (скажем поправить орфографическую ошибку в комменте), возникает "голова", которую и не грех собрать gc. Без именнованных веток работать можно, но бессмысленно, человекам имена понятнее, чем циферки. Комфорт работы с безымяными ветками в hg является удобством лишь в сравнении с тем, что с именованными ветками работать хреново.
Скажем, изменения приезжающие из других репозитоиев появляются как безымянные головы именованной ветки — нужно догадываться что откуда. В git они приезжают с префиксом имени других репозиториев, human friendliness, однако.
_>>>Первый раз про такое слышу. Использовать ветки для ситуации без ветвления. Это похоже только от убогости других инструментов git'a. _>·>Ещё раз. Оно расходится _может_, но не обязательно что _будет_. Скажем, если мы зарелизили что-то и оно всё сразу суперски заработало с первого раза — релиз будет в точности равен тому что надевелопилось. А если мы сделали поверх релиза хотфикс(ы) — ветки разойдутся. _>Ну и пускай расходятся просто так — в mercurial всё равно же не обязательны именованные ветки/закладки для этого. Собственно ситуация кратковременного ответвления идеальна для реализации через анонимные ветки. _>А вот реальные именованные ветки/закладки есть смысл использовать при наличие логически выделенных веток разработки, а не для синхронизации работы или установки каких-то меток (для этого есть теги).
А вот представь себе, что в гите неважно кратковременно или долговременно что-то ответвляется. Механизмы те же, инструменты те же, команды те же, и то, и то использовать просто.
_>·>Пусть другой граф, пороще, с расхождением, мержем и одной веткой: _>·>
_>Ну так ты поясни что это. Я вот вижу некую ветку, которая разделяется и потом сливается. Это понятно и нормально. Потом я вижу некую метку "development" на последней ревизии ветки. Что она у тебя должна означать? )
Пусть именованную ветку или закладку. Не важно. Покажи на этом рисунке "a linear sequence of consecutive changesets", например.
_>·>Что ещё за указатели на ветки? Есть просто reference (ссылка) и всё. Сссылка с префиксом refs/heads/ является веткой, с префиксом refs/tags/ — тегом, с префиксом refs/remotes/ — ссылки из чужих репо, и т.п. Там же и stash, там же и notes и кастомные вещи, типа pull requests гитхаба. _>·>Команды какие ещё? update-ref только, остальные (branch, tag, notes) просто надстройки — для удобства человеков только. _>ОК, а если у нас репозитории ревизия на которую нет ссылок через ветки/теги, то как нам с ней работать? )
А почему нет? Создать ссылку — элементарно, ничего не стоит, никаких проблем не создаёт, если вдруг мешается, можно удалить, никаких последствий.
А если ты робот и тебе надо без ссылок, всегда есть id.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, AK107, Вы писали:
AK>ну вот реальный пример из последних.
AK>дано: большой класс (файл). AK>хочу: сделать его parital (разбить на два файла), соответственно "половина" функционал пойдет в один файл, половина в другой. оба имени файла отличные от оригинального, название класса тоже изменилось, попутно что-то пофиксилось.
AK>что скажет история git про эти два новых файла? как они будут связаны с оригиналом?
git пытается восстановить происшедшее, сравнивая содержимое файлов. Скажем, git blame -C сможет показать строчки в новых файлах как переехавшие из старого.
Этот процесс основан на нечётких сравнениях строчек. Поэтому, желательно такие громадные изменения делать серией мелких коммитов — это будет проще отследить не только гиту, но и человеку делающему ревью, и тебе самому пол года спустя.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Как локальная закладка будет отслеживать голову именованной ветки? Никак.
Не понял. Задача локальной закладки, которую я устанавливаю в своём репозитории, — показывать мне место, на котором я остановился. Если кто-то закоммитит в мою ветку, закладка продолжит показывать мне ревизию, на которой остановился именно я.
Петя поставил локальную закладку, сделал коммит, пуш, и ушел домой. Маша посмотрела на это дело, внесла исправление, закомимтила, запушила и ушла домой. Петя утром пришёл, сделал pull, увидел место, на котором он остановился вчера, и ещё увидел, что Маша кое-что добавила:
Петя просмотрел Машины изменения, ему они понравились. Он передвинул закладку на Машину ревизию и продолжил работу с неё:
Или не понравились. "Что за фигня?" — подумал Петя и продолжил работу с того места, на котором остановился в прошлый раз.
A>>Или они могут каждый сделать себе по закладке и сказать синхронизировать их между репозиториями. ·>Не могут. Проблема ровно та же: "Be aware that there is only one namespace for bookmarks — it is advised to prefix your local-only bookmarks to avoid conflicts with other users. "
Допустим, у Маши с Петей отсутствует фантазия. Маша закоммитила, поставила синхронизируемую закладку, запушила. Петя закоммитил у себя и поставил закладку с таким же именем. Попробовал её синхронизировать, но оказалось, что закладка с таким именем уже есть. Петя переименовал свою закладку, и они жили долго и счастливо.
A>>Могут под свои задачи именованные ветки завести, если захотят или потребуется зачем-то. ·>Ветки же уже заведены — с именем "experiment". Надо будет кому-то из них ветку переименовывать, переписывая историю. А от этой истории уже могут другие зависимости существовать...
В худшем случае, если Маша с Петей две недели пахали локально в ветках с одинаковым названием, успели наделать много-много ревизий, даже успели засветить где-то на стороне хеши этих ревизий, а потом одновременно запушили на сервер, так что ни у кого из них не было шанса заранее узнать о совпадении имён ― ну, значит, пока будет две ветки "experiment". Хоть три. Можно их сразу закрыть и продолжить с новыми внятными названиями. Можно повесить закладки. Можно оставить как есть.
Я толком не пользовался Гитом и не могу прочувствовать проблему совпадения имён.
A>>Маша и Петя спокойно обошлись без именованных веток, без bookmarks, без тэгов, вообще без всего. ·>Т.к. при совпадении имён веток, Маша может вытянуть ветку Пети под другим именем, скажем, назвать её в своём репозитории как petya_dev. По смыслу — ветки dev у Пети и у Маши — независимые истории.
Вот на самом деле зачем Маше Петина ветка под другим именем? По смыслу это одна ветка, у который есть своё имя (если есть). С чего его вдруг менять?
A>>·> Почему их нужно насильно сталкивать лишь по тому, что у них случайно совпали имена — хз. A>>Я думаю, слово "нужно" неверно. Устраивает базовый функционал анонимных веток? Пользуешься им. Испытываешь неудобства? Можешь использовать закладки и/или именованные ветки. ·>Как выяснилось выше — не могу, проблему они не решают.
Чем больше перечитываю, тем больше не понимаю, о чём речь. Что конкретно ты не можешь? Hg ругается на совпадение имён, виснет, теряет данные или не даёт коммитить, пушить и т.д.? Ему пофиг.
·>Вот. Уже внезапно стало три анонимные ветки, различать их стало ещё сложнее.
Там всё было подписано.
A>>Если использовать только неименованные ветки, то просто увидит, что из одной из ревизий, над которыми он работал, выросла новая голова. A>>Если он знает, что ему так будет неудобно, он может озаботиться, например, использованием синхронизируемых закладок. Тогда он тоже увидит три головные ревизии, но они будут подписаны: ·>Та же проблема, имена закладок глобальны, да ещё и пушатся без спросу — думай тщательно каждый раз когда даёшь название.
Можно тщательно думать, давая имена. Можно не думать, давая имена. Можно не давать имена. Имена не на что не влияют.
Я так понял из разговоров, что Гит заставляет давать каждой головной ревизии уникальные в пределах репозитория имена. Но поскольку головных ревизий бывает много, а слов в языке мало, то названия совершенно разных веток в разных репозиториях периодически совпадают. И тогда чтобы влить в один репозиторий изменения из другого, иногда приходится чужие ветки у себя переименовывать. И тогда в разных репозиториях совершенно разные ветки могут называться одинаково, а одна и та же ветка может называться по-разному. Отсюда, наверное, такая любовь и ненависть к именам?
Здравствуйте, alexzz, Вы писали:
A>Допустим, у Маши с Петей отсутствует фантазия. Маша закоммитила, поставила синхронизируемую закладку, запушила. Петя закоммитил у себя и поставил закладку с таким же именем. Попробовал её синхронизировать, но оказалось, что закладка с таким именем уже есть. Петя переименовал свою закладку, и они жили долго и счастливо.
Вроде я понял чего тебе не понятно. hg имеет жуткое cvcs наследие, которым жестоко коцают мозги юзеров. Ты видишь только два репозитория, притом один из них более главный, или ещё "центральный сервер". А в dvcs — репозиториев потенциально бесконечно и они все равноправны. Маша и Петя это могут быть две БОЛЬШИЕ команды. И закладка команды ПЕТЯ уже разползлась в 1000 реп, закладка команды МАША в 2000 реп. И вот теперь приходит тут такая МАША и указывает ПЕТЕ что он у себя всё везде обязан поменять, т.к. МАША так хочет, как думаешь, куда пошлёт её ПЕТЯ?
A>>>Могут под свои задачи именованные ветки завести, если захотят или потребуется зачем-то. A>·>Ветки же уже заведены — с именем "experiment". Надо будет кому-то из них ветку переименовывать, переписывая историю. А от этой истории уже могут другие зависимости существовать... A>В худшем случае, если Маша с Петей две недели пахали локально в ветках с одинаковым названием, успели наделать много-много ревизий, даже успели засветить где-то на стороне хеши этих ревизий, а потом одновременно запушили на сервер, так что ни у кого из них не было шанса заранее узнать о совпадении имён ― ну, значит, пока будет две ветки "experiment". Хоть три. Можно их сразу закрыть и продолжить с новыми внятными названиями. Можно повесить закладки. Можно оставить как есть.
Это называется ripple effect — где-то небольшая проблема и все вокруг везде должны всё менять, вместо того, чтобы сделать локальное согласование только в точке взаимодействия.
A>Я толком не пользовался Гитом и не могу прочувствовать проблему совпадения имён.
Ты похоже, просто толком мне пользовался dvcs. Это не проблема git, это проблема распределённой разработки.
A>>>Маша и Петя спокойно обошлись без именованных веток, без bookmarks, без тэгов, вообще без всего. A>·>Т.к. при совпадении имён веток, Маша может вытянуть ветку Пети под другим именем, скажем, назвать её в своём репозитории как petya_dev. По смыслу — ветки dev у Пети и у Маши — независимые истории. A>Вот на самом деле зачем Маше Петина ветка под другим именем? По смыслу это одна ветка, у который есть своё имя (если есть). С чего его вдруг менять?
Чтобы их легко различать по имени, а не по неким косвенным признакам.
A>>>·> Почему их нужно насильно сталкивать лишь по тому, что у них случайно совпали имена — хз. A>>>Я думаю, слово "нужно" неверно. Устраивает базовый функционал анонимных веток? Пользуешься им. Испытываешь неудобства? Можешь использовать закладки и/или именованные ветки. A>·>Как выяснилось выше — не могу, проблему они не решают. A>Чем больше перечитываю, тем больше не понимаю, о чём речь. Что конкретно ты не можешь? Hg ругается на совпадение имён, виснет, теряет данные или не даёт коммитить, пушить и т.д.? Ему пофиг.
Ему пофиг на человеков: люди умные — захотят, разберутся.
A>·>Вот. Уже внезапно стало три анонимные ветки, различать их стало ещё сложнее. A>Там всё было подписано.
Т.е. если и Маша, и Петя удосужатся всё аккуратно подписывать и они чётко договорятся как именно подписывать, то возможно разберутся.
A>·>Та же проблема, имена закладок глобальны, да ещё и пушатся без спросу — думай тщательно каждый раз когда даёшь название. A>Можно тщательно думать, давая имена. Можно не думать, давая имена. Можно не давать имена. Имена не на что не влияют.
Они влияют на конфликты.
A>Я так понял из разговоров, что Гит заставляет давать каждой головной ревизии уникальные в пределах репозитория имена.
Нет, гит _сам_ добавляет префикс к имени. Хотя не обязательно, можно и без имён обойтись Например, дефолтным именем FETCH_HEAD
A>Но поскольку головных ревизий бывает много, а слов в языке мало, то названия совершенно разных веток в разных репозиториях периодически совпадают. И тогда чтобы влить в один репозиторий изменения из другого, иногда приходится чужие ветки у себя переименовывать. И тогда в разных репозиториях совершенно разные ветки могут называться одинаково, а одна и та же ветка может называться по-разному. Отсюда, наверное, такая любовь и ненависть к именам?
Они совадают потому что репозитории разные и независимые, потенциально — без какого либо централизованного контроля, distributed vcs однако.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Зато применяются по делу, в отличие от git. _>>Смотри, в mercurial и именновые ветки и закладки (выбираешь в зависимости от своего вкуса) применяются исключительно для выделения долгоживующих сущностей. Т.е. если у тебя реально в репозитории намечаются две принципиально разные ветки (скорее всего созданные в самом начале истории), то надо применять что-то из этой области. Если же у тебя реально только одна ветка, которая периодически разделяется и сливается из-за синхронизации работы команды, то выделенные именные сущности просто не нужны. ·>Собственно по-моему это и есть философское отличие. В hg ты должен заранее решить что и как ты делаешь, что у тебя намечается и в зависимости от этого выбирать какой-то из механизмов, если ты принял неверное решение — исправить ситуацию довольно геморно. В git принципиальной разницы нет. Сделай как-нибудь что-нибудь как кажется правильным на текущий момент, а потом, если что, поменяешь как надо, когда будешь точно знать что тебе надо.
Эм, никакой технической проблемы поменять расклад в Mercurial в любой момент. Это я тебе рассказал наиболее логичный и удобный подход на мой взгляд, а не ограничение системы.
_>>В Git же приходится применять ветки не только для реальных выделенных сущностей, но но и для обслуживания ситуации синхронизации параллельной разработки в одной (смысловой) ветке. ·>Ты так говоришь, как будто это что-то плохое. В стандартном случае у тебя после clone будет две ветки — master — твоя работа и origin/master — ветка оригинального репозитория. Ты сразу можешь точно видеть где твоё, а что идёт от других.
Вот уж свою ветку со своими комментариями к ревизиям я уж как-нибудь отличу от чужих. )))
·>Да, верно. Чтобы появилось имя ветки надо сделать коммит, даже если содержимое X и Y идентично (тот же snapshot), их sha1 будет разный. ·>Т.е. если строгаю я всё в default-ветке, потом создаю release_candidate, и продолжу строгать default — появится расхождение графа ревизий. Это алогично, ведь по факту, с т.з. моих рабочих файлов — никаких расхождений нет, история изменений working copy — линейная. release_candidate не разхождение ревизий, а просто left behind ветка, которую можно fast forward. ·>Расхождение должно появиться только в том случае, если я внёс изменение и в release_candidate, и в default, т.е. появилась ревизия с двумя детьми. А что собственно значит появилось расхождение — это значит, что появилась "альтернативная история", которую можно 3-way мержить.
Ммм, так а ты объясни тогда зачем в твоём сценарии создавать новую ветку и делать в ней пустую ревизию?
_>>Ну и да, это бредовый способ использования именованных веток (т.к. собственно ветвления тут нет) и его никто не использует. Но если очень хочется (я правда так и не понял зачем оно тебе такое было надо), то технически возможно. ·>Да, закладки — как возможное решение. Остаётся вопрос — накой нужны ветки. И почему "это" называется "веткой" в hg.
Формально оно называется "именем ветки" и при этом несколько веток официально могут иметь одно название. ))) Но согласен, что название не совсем удачное. Что касается функциональности, то из их фундаментального отличия (имя ветки идентифицирует целый набор ревизий, а закладка только одну) следует и большая разница в применение. Например имена веток остаются навсегда в истории, что очень полезно для отслеживание работы команды. Кроме того, имена веток не реагируют (наследуются в обе части) на мелкие анонимные разветвления, а закладки соответственно идут только по какому-то одному пути. Так что разница принципиальная. И лично мне для выделения принципиальных долгоживущих частей истории проекта больше нравится использовать именные ветки, а не закладки. Но это дело вкуса. В Mercurial богатый выбор вариантов, в отличие от Git. )))
_>>В том то и дело, что не так же. Нет в git нормальной работы на уровне чистых ревизий. Вот к примеру как мне узнать список всех "голов" в хранилище? Я уже молчу про то, что git-gc может самовольно удалять подобные данные. Нет, в git нельзя нормально работать без именованных веток, хотя внутри у него в базисе такая же основа как и у mercurial. Но не смогли... ·>Голов слишком много, их можно найти через "fsck", или через "reflog". Например, когда правишь коммит (скажем поправить орфографическую ошибку в комменте), возникает "голова", которую и не грех собрать gc. Без именнованных веток работать можно, но бессмысленно, человекам имена понятнее, чем циферки. Комфорт работы с безымяными ветками в hg является удобством лишь в сравнении с тем, что с именованными ветками работать хреново.
Ну т.е. как я и говорил, нормально работать с анонимными ветками в Git нельзя. Несмотря на то, что где-то на низком уровне там как раз такой же механизм (хэши и связи). Но не смогли...
·>Скажем, изменения приезжающие из других репозитоиев появляются как безымянные головы именованной ветки — нужно догадываться что откуда. В git они приезжают с префиксом имени других репозиториев, human friendliness, однако.
Смешно) В Git мы имеем ровно один способ реализации ветвлений. А в Mercurial мы имеем 3 разных способа (причём один из них совпадает с реализацией в Git) — используй какой тебе больше по вкусу, никто не ограничивает. Но при этом ты считаешь, что Git в этом смысле лучше? )))
_>>А вот реальные именованные ветки/закладки есть смысл использовать при наличие логически выделенных веток разработки, а не для синхронизации работы или установки каких-то меток (для этого есть теги). ·>А вот представь себе, что в гите неважно кратковременно или долговременно что-то ответвляется. Механизмы те же, инструменты те же, команды те же, и то, и то использовать просто.
Собственно я ещё в самом начале дискуссии сказал, что данный вопрос больше дело вкуса. )
_>>·>Пусть другой граф, пороще, с расхождением, мержем и одной веткой: _>>·>
_>>Ну так ты поясни что это. Я вот вижу некую ветку, которая разделяется и потом сливается. Это понятно и нормально. Потом я вижу некую метку "development" на последней ревизии ветки. Что она у тебя должна означать? ) ·>Пусть именованную ветку или закладку. Не важно. Покажи на этом рисунке "a linear sequence of consecutive changesets", например.
Ну вот то, что ты нарисовал — это оно и есть как раз. ) В начале одна линия, потом разделяется на две, потом сливается снова в одну. ) Что тут может быть непонятного? )
_>>ОК, а если у нас репозитории ревизия на которую нет ссылок через ветки/теги, то как нам с ней работать? ) ·>А почему нет? Создать ссылку — элементарно, ничего не стоит, никаких проблем не создаёт, если вдруг мешается, можно удалить, никаких последствий.
Про Оккама забываем? )))
·>А если ты робот и тебе надо без ссылок, всегда есть id.
Да, вот только робот и может пользоваться анонимными ветками в git (записывая на бумажку хеши и отключив при этом git-gc).
Здравствуйте, ·, Вы писали:
AK>>что скажет история git про эти два новых файла? как они будут связаны с оригиналом? ·>git пытается восстановить происшедшее, сравнивая содержимое файлов. Скажем, git blame -C сможет показать строчки в новых файлах как переехавшие из старого. ·>Этот процесс основан на нечётких сравнениях строчек. Поэтому, желательно такие громадные изменения делать серией мелких коммитов — это будет проще отследить не только гиту, но и человеку делающему ревью, и тебе самому пол года спустя.
Хехе, а если взглянуть на это с точки зрения нашей дискуссии.. Ты в курсе наличие в Mercurial команд copy/rename/remove? )))
Здравствуйте, ·, Вы писали:
·>Вроде я понял чего тебе не понятно. hg имеет жуткое cvcs наследие, которым жестоко коцают мозги юзеров. Ты видишь только два репозитория, притом один из них более главный, или ещё "центральный сервер". А в dvcs — репозиториев потенциально бесконечно и они все равноправны. Маша и Петя это могут быть две БОЛЬШИЕ команды. И закладка команды ПЕТЯ уже разползлась в 1000 реп, закладка команды МАША в 2000 реп. И вот теперь приходит тут такая МАША и указывает ПЕТЕ что он у себя всё везде обязан поменять, т.к. МАША так хочет, как думаешь, куда пошлёт её ПЕТЯ?
Нет, подходы совсем не такие, хотя действительно различаются:
1. В централизованных VCS имеем ровно одно хранилище где-то на сервере, а у пользователей нет ничего. Соответственно в синхронизированном состояние у всех абсолютно одинаковая картинка.
2. В Mercurial у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом в синхронизированном состояние она у всех одинаковая.
3. В Git у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом у каждого репозиторий выглядит по разному (разные имена веток соответствую разным реальным ревизиям и т.д.).
Здравствуйте, Dair, Вы писали:
D>Диспозиция: я в своей ветке, наменял разного, делаю коммит (не push) и готовлюсь взять последюю версию от коллег из develop, чтобы не сильно отставать. Для этого надо мне тут сделать commit, переключиться на общий develop, сделать pull, переключиться обратно, сделать merge.
Строго говоря нет, не нужно переключать ветки. Если ты не изменял ничего в своей локальной версии develop-a, то можно сделать просто
git fetch origin develop:develop
Еще лучше просто написать alias и делать в одну команду все это.
Здравствуйте, netch80, Вы писали:
N>Слушай, а у тебя с RAM, шиной и т.п. на данном компе всё в порядке? N>Ничем иным я объяснить подобные чудеса на сейчас не могу, кроме как битым железом.
Скорее всего crlf настройки разные стоят у разных членов команды.
Боянная проблема гитоводов.
Здравствуйте, netch80, Вы писали:
N>Если авторы не в состоянии отработать с точки зрения даже простейший сценарий использования, как можно предлагать использовать их творение?
Резюмирую твои проблемы и вопросы: ты просто не прочитал документацию
Гит в этом плане еще хуже, там нормально пользоваться нельзя пока ты досконально не прочитаешь хотя бы git-scm book.
Вообще то что по использованию гита книги пишут уже хороший показатель "удобства" инструмента. Тот же svn я пользовал из под гуя несколько лет и только пару раз заглядывал в документацию. Просто не было необходимости такой. По гиту то и дело лезу то на стек, то в handbook, то в гугл.
·>Что ещё за указатели на ветки? Есть просто reference (ссылка) и всё. Сссылка с префиксом refs/heads/ является веткой, с префиксом refs/tags/ — тегом, с префиксом refs/remotes/ — ссылки из чужих репо, и т.п. Там же и stash, там же и notes и кастомные вещи, типа pull requests гитхаба. ·>Команды какие ещё? update-ref только, остальные (branch, tag, notes) просто надстройки — для удобства человеков только.
Можно как-то откатиться на коммит HEAD~N и увидеть все эти ветки в том виде как они были на тот момент на сервере (тот что origin). Считаем что за давностью лет все эти ветки и метки на origin давно потерты.
Здравствуйте, woah, Вы писали:
W>Можно как-то откатиться на коммит HEAD~N и увидеть все эти ветки в том виде как они были на тот момент на сервере (тот что origin). Считаем что за давностью лет все эти ветки и метки на origin давно потерты.
Что значит "откатиться"? У нас не централизованная VCS, некуда откатываться.
Можно посмотреть какие в репозитории были названия голов в данное время.
Здравствуйте, alex_public, Вы писали:
_>·>Собственно по-моему это и есть философское отличие. В hg ты должен заранее решить что и как ты делаешь, что у тебя намечается и в зависимости от этого выбирать какой-то из механизмов, если ты принял неверное решение — исправить ситуацию довольно геморно. В git принципиальной разницы нет. Сделай как-нибудь что-нибудь как кажется правильным на текущий момент, а потом, если что, поменяешь как надо, когда будешь точно знать что тебе надо. _>Эм, никакой технической проблемы поменять расклад в Mercurial в любой момент. Это я тебе рассказал наиболее логичный и удобный подход на мой взгляд, а не ограничение системы.
Как ты branch переделаешь в bookmark?
Ты говоришь, мол это для короткоживущих, это для долгоживущих... Как ты это определяешь? Ты знаешь будущее? Я не ясновидец, я не умею и не хочу думать об этом выборе. Почему это должно отличаться?
_>>>В Git же приходится применять ветки не только для реальных выделенных сущностей, но но и для обслуживания ситуации синхронизации параллельной разработки в одной (смысловой) ветке. _>·>Ты так говоришь, как будто это что-то плохое. В стандартном случае у тебя после clone будет две ветки — master — твоя работа и origin/master — ветка оригинального репозитория. Ты сразу можешь точно видеть где твоё, а что идёт от других. _>Вот уж свою ветку со своими комментариями к ревизиям я уж как-нибудь отличу от чужих. )))
Вот и говорю — явно отличить невозможно, приходится полагаться на косвенные признаки.
_>·>Расхождение должно появиться только в том случае, если я внёс изменение и в release_candidate, и в default, т.е. появилась ревизия с двумя детьми. А что собственно значит появилось расхождение — это значит, что появилась "альтернативная история", которую можно 3-way мержить. _>Ммм, так а ты объясни тогда зачем в твоём сценарии создавать новую ветку и делать в ней пустую ревизию?
А разве можно запушить ветку, если она не закоммичена?
_>>>Ну и да, это бредовый способ использования именованных веток (т.к. собственно ветвления тут нет) и его никто не использует. Но если очень хочется (я правда так и не понял зачем оно тебе такое было надо), то технически возможно. _>·>Да, закладки — как возможное решение. Остаётся вопрос — накой нужны ветки. И почему "это" называется "веткой" в hg. _>Формально оно называется "именем ветки" и при этом несколько веток официально могут иметь одно название. ))) Но согласен, что название не совсем удачное.
Не знаю откуда ты берёшь это "формально", в официальной документации это называется named branch, "именованная ветка". Да и команды, работающие с ними "hg branch", "hg branches". "--branch".
_>Что касается функциональности, то из их фундаментального отличия (имя ветки идентифицирует целый набор ревизий, а закладка только одну) следует и большая разница в применение. Например имена веток остаются навсегда в истории, что очень полезно для отслеживание работы команды. Кроме того, имена веток не реагируют (наследуются в обе части) на мелкие анонимные разветвления, а закладки соответственно идут только по какому-то одному пути. Так что разница принципиальная. И лично мне для выделения принципиальных долгоживущих частей истории проекта больше нравится использовать именные ветки, а не закладки. Но это дело вкуса. В Mercurial богатый выбор вариантов, в отличие от Git. )))
Польза мне не очевидна. Я за минимализм. Если что-то понадобится, выберешь какой-то подход для этого конкретного требования. Проще линк(и) какой-нибудь добавить более подходящий в коммент: "Bug: 1235", "Story: AB-5565", "Sprint: 17" и т.п. Ветками такое выразить уже не выйдет.
_>·>Голов слишком много, их можно найти через "fsck", или через "reflog". Например, когда правишь коммит (скажем поправить орфографическую ошибку в комменте), возникает "голова", которую и не грех собрать gc. Без именнованных веток работать можно, но бессмысленно, человекам имена понятнее, чем циферки. Комфорт работы с безымяными ветками в hg является удобством лишь в сравнении с тем, что с именованными ветками работать хреново. _>Ну т.е. как я и говорил, нормально работать с анонимными ветками в Git нельзя. Несмотря на то, что где-то на низком уровне там как раз такой же механизм (хэши и связи). Но не смогли...
Я не понимаю что ты подразумеваешь под нормально работать. Зачем вообще с анонимными ветками работать? Особенно в случае, если с именованными проблем никаких.
_>·>Скажем, изменения приезжающие из других репозитоиев появляются как безымянные головы именованной ветки — нужно догадываться что откуда. В git они приезжают с префиксом имени других репозиториев, human friendliness, однако. _>Смешно) В Git мы имеем ровно один способ реализации ветвлений. А в Mercurial мы имеем 3 разных способа (причём один из них совпадает с реализацией в Git) — используй какой тебе больше по вкусу, никто не ограничивает. Но при этом ты считаешь, что Git в этом смысле лучше? )))
Букмарки не совпадают с git, имеют неразрешимые проблемы. Так что я предпочту один способ, но универсальный, чем три — но ограниченных. Эти проблемы, надеюсь, уже пофиксили?
_>>>А вот реальные именованные ветки/закладки есть смысл использовать при наличие логически выделенных веток разработки, а не для синхронизации работы или установки каких-то меток (для этого есть теги). _>·>А вот представь себе, что в гите неважно кратковременно или долговременно что-то ответвляется. Механизмы те же, инструменты те же, команды те же, и то, и то использовать просто. _>Собственно я ещё в самом начале дискуссии сказал, что данный вопрос больше дело вкуса. )
Хорошо, пусть дело вкуса. Но смысла уж точно нет.
_>>>·>Пусть другой граф, пороще, с расхождением, мержем и одной веткой: _>>>·>
_>>>Ну так ты поясни что это. Я вот вижу некую ветку, которая разделяется и потом сливается. Это понятно и нормально. Потом я вижу некую метку "development" на последней ревизии ветки. Что она у тебя должна означать? ) _>·>Пусть именованную ветку или закладку. Не важно. Покажи на этом рисунке "a linear sequence of consecutive changesets", например. _>Ну вот то, что ты нарисовал — это оно и есть как раз. ) В начале одна линия, потом разделяется на две, потом сливается снова в одну. ) Что тут может быть непонятного? )
Не понял. В каком начале? Это текущий граф, текущая история. sequence может быть выражена как последовательность точек. Я поменял граф, обозначив точки уникально. Перечисли эти линии.
_>>>ОК, а если у нас репозитории ревизия на которую нет ссылок через ветки/теги, то как нам с ней работать? ) _>·>А почему нет? Создать ссылку — элементарно, ничего не стоит, никаких проблем не создаёт, если вдруг мешается, можно удалить, никаких последствий. _>Про Оккама забываем? )))
В hg об Оккаме и не всмоминали: помимо "именованных веток" ввели сущность "анонимные ветки" и прочие закладки с головами.
Мне вообще интересно, опиши сценарий: откуда в git появится ревизия на которую нет ссылкок и что ты с ней хочешь делать, для чего она тебе может понадобится?
_>·>А если ты робот и тебе надо без ссылок, всегда есть id. _>Да, вот только робот и может пользоваться анонимными ветками в git (записывая на бумажку хеши и отключив при этом git-gc).
Человек тоже может, но только стоя в гамаке, надев противогаз.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
AK>>>что скажет история git про эти два новых файла? как они будут связаны с оригиналом? _>·>git пытается восстановить происшедшее, сравнивая содержимое файлов. Скажем, git blame -C сможет показать строчки в новых файлах как переехавшие из старого. _>·>Этот процесс основан на нечётких сравнениях строчек. Поэтому, желательно такие громадные изменения делать серией мелких коммитов — это будет проще отследить не только гиту, но и человеку делающему ревью, и тебе самому пол года спустя. _>Хехе, а если взглянуть на это с точки зрения нашей дискуссии.. Ты в курсе наличие в Mercurial команд copy/rename/remove? )))
Ага, круто, конечно, сразу видно, Бритва тупая попалась. Но как оно поможет разделить один файл на два новых?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>1. В централизованных VCS имеем ровно одно хранилище где-то на сервере, а у пользователей нет ничего. Соответственно в синхронизированном состояние у всех абсолютно одинаковая картинка. _>2. В Mercurial у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом в синхронизированном состояние она у всех одинаковая.
Враньё же... Показывали же тут эти картинки — выглядят по-разному, т.к. корёжатся локальными номерами ревизий.
Ещё интересно, что же такое "синхронизованное состояние у всех" в dvcs. Ты имеешь в виду "после полной синхронизации всего между парой репозиториев"?
_>3. В Git у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом у каждого репозиторий выглядит по разному (разные имена веток соответствую разным реальным ревизиям и т.д.).
Неверно. Имена веток совпадают. Ремотные ветки имеют то же имя что и ветки в ремотном репо. Другое дело, что при необходимости их _можно_ замапить под другим именем на локальные.
_>Лично мне больше всего нравится вариант 2.
Если только дело вкуса.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
