Здравствуйте, woah, Вы писали:
W>·>Ещё можно просто по sha1 обращаться. Можно reflog полистать, можно в stash закинуть. Вариантов куча. W> И ни один неудобен для человека.
В каком случае ты столкнёшься с этим неудобством? Опиши сценарий.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Эм, никакой технической проблемы поменять расклад в Mercurial в любой момент. Это я тебе рассказал наиболее логичный и удобный подход на мой взгляд, а не ограничение системы. ·>Как ты branch переделаешь в bookmark? ·>Ты говоришь, мол это для короткоживущих, это для долгоживущих... Как ты это определяешь? Ты знаешь будущее? Я не ясновидец, я не умею и не хочу думать об этом выборе. Почему это должно отличаться?
Зачем переделывать одно в другое? ) Они же все совместимы между собой. Собственно их так обычно и используют. Вот нужна тебе долгоживущая ветка — устанавливаешь имя. Требуется мелкое ответвление в ней — используешь анонимные ветки (правда в данном случае они на самом деле будут не анонимные, а просто с совпадающими именами изначальной). Хочешь как-то выделить одну из этих анонимных подветок — ставишь на неё закладку. ) В общем всё полностью совместимо на любом уровне.
_>>·>Расхождение должно появиться только в том случае, если я внёс изменение и в release_candidate, и в default, т.е. появилась ревизия с двумя детьми. А что собственно значит появилось расхождение — это значит, что появилась "альтернативная история", которую можно 3-way мержить. _>>Ммм, так а ты объясни тогда зачем в твоём сценарии создавать новую ветку и делать в ней пустую ревизию? ·>А разве можно запушить ветку, если она не закоммичена?
А что значит "запушить ветку"? ) И зачем это надо? )
_>>Формально оно называется "именем ветки" и при этом несколько веток официально могут иметь одно название. ))) Но согласен, что название не совсем удачное. ·>Не знаю откуда ты берёшь это "формально", в официальной документации это называется named branch, "именованная ветка". Да и команды, работающие с ними "hg branch", "hg branches". "--branch".
Да, имена команд тоже неудачно вышли, хотя понятно что это так для краткости. Но тут вообще непонятно как было правильно назвать. Смотри, тут есть:
— ветки. Это которые мы в данной дискуссии называем анонимными (хотя на самом деле это неверно, т.к. у любой из них на самом деле есть имя (default или какое-то другое), просто оно может совпадать с именем соседней ветки).
— имена веток. Просто атрибут у каждой ревизии.
Так вот команды hg branch и т.п. работают как раз с именами веток, так что теоретически должны были бы называться как-то типа branch_name и т.п. Но это же тоже бредово... )
_>>Ну т.е. как я и говорил, нормально работать с анонимными ветками в Git нельзя. Несмотря на то, что где-то на низком уровне там как раз такой же механизм (хэши и связи). Но не смогли... ·>Я не понимаю что ты подразумеваешь под нормально работать. Зачем вообще с анонимными ветками работать? Особенно в случае, если с именованными проблем никаких.
Это уже отдельный вопрос (который мы вроде как тоже параллельно обсуждаем). Но вне зависимости от его результатов у нас останется тот факт, что в Git отсутствует имеющаяся в Mercurial возможность работы с анонимными ветками.
_>>Смешно) В Git мы имеем ровно один способ реализации ветвлений. А в Mercurial мы имеем 3 разных способа (причём один из них совпадает с реализацией в Git) — используй какой тебе больше по вкусу, никто не ограничивает. Но при этом ты считаешь, что Git в этом смысле лучше? ))) ·>Букмарки не совпадают с git, имеют неразрешимые проблемы. Так что я предпочту один способ, но универсальный, чем три — но ограниченных.
Что за неразрешимые проблемы? )
·>Эти проблемы, надеюсь, уже пофиксили?
Хы, к mercurial там ровно две претензии:
1. не позволяет подчищать репозиторий задним числом без особых манипуляций. Смешно, т.к. сохранности историй — это один из базовых принципов Mercurial.
2. не позволяет сделать push закладки. Видимо автор не в курсе про параметр -B у команды push. )))
_>>Собственно я ещё в самом начале дискуссии сказал, что данный вопрос больше дело вкуса. ) ·>Хорошо, пусть дело вкуса. Но смысла уж точно нет.
Вот не надо только пропагандировать тут подход Apple — в профессиональной среде он плохо проходит. )))
_>>>>·>Пусть другой граф, пороще, с расхождением, мержем и одной веткой: _>>>>·>
_>>>>Ну так ты поясни что это. Я вот вижу некую ветку, которая разделяется и потом сливается. Это понятно и нормально. Потом я вижу некую метку "development" на последней ревизии ветки. Что она у тебя должна означать? ) _>>·>Пусть именованную ветку или закладку. Не важно. Покажи на этом рисунке "a linear sequence of consecutive changesets", например. _>>Ну вот то, что ты нарисовал — это оно и есть как раз. ) В начале одна линия, потом разделяется на две, потом сливается снова в одну. ) Что тут может быть непонятного? ) ·>Не понял. В каком начале? Это текущий граф, текущая история. sequence может быть выражена как последовательность точек. Я поменял граф, обозначив точки уникально. Перечисли эти линии.
Я так и не понял что ты хочешь))) Точнее не пойму чем тебя не устраивает мой ответ в первом же сообщение (много страниц назад). Ну да ладно, мне не сложно повторить в сотый раз, уже с буковками. ))) Последовательности ревизий: {a, b, c}, {d, e, f}, {g}, {h, i, j, k}.
·>В hg об Оккаме и не всмоминали: помимо "именованных веток" ввели сущность "анонимные ветки" и прочие закладки с головами. ·>Мне вообще интересно, опиши сценарий: откуда в git появится ревизия на которую нет ссылкок и что ты с ней хочешь делать, для чего она тебе может понадобится?
Ну вот работаю над каким-то проектом, решил проверить некое решение, закодировал, убедился что оно сейчас не подходит (но код полезный и пригодится в будущем), зафиксировал его в виде ревизии, откатился назад на одну ревизий и пошёл работать дальше, создавая новые ревизии. При этом у меня там останется маленький отросток (ветка из одной ревизии), который возможно когда-нибудь пригодится.
Это я описал сценарий в Mercurial. А как оно будет в Git? ) Будешь создавать по каждому такому поводу отдельную ветку с новым именем? )
Кстати, возвращаясь к дискуссии выше о совместимости разных техник. Если я захочу, то я могу поставить данному отростку (и всем остальным подобным) имя ветки "experimental" и это отлично сработает. Не смотря на то, что в реальности данные отростки не образуют связное дерево.
Здравствуйте, ·, Вы писали:
_>>Хехе, а если взглянуть на это с точки зрения нашей дискуссии.. Ты в курсе наличие в Mercurial команд copy/rename/remove? ))) ·>Ага, круто, конечно, сразу видно, Бритва тупая попалась. Но как оно поможет разделить один файл на два новых?
Эм, ну вообще то даже без всяких VCS, разделение обычно производят через копирование файла и потом стирания в каждой копии ненужного. )))
Здравствуйте, ·, Вы писали:
_>>1. В централизованных VCS имеем ровно одно хранилище где-то на сервере, а у пользователей нет ничего. Соответственно в синхронизированном состояние у всех абсолютно одинаковая картинка. _>>2. В Mercurial у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом в синхронизированном состояние она у всех одинаковая. ·>Враньё же... Показывали же тут эти картинки — выглядят по-разному, т.к. корёжатся локальными номерами ревизий.
Это типа юмор? ))) Тогда уж у разных участников команды возможно ещё и разные GUI к Mercurial и там уж точно по разному деревья рисуются... )))
·>Ещё интересно, что же такое "синхронизованное состояние у всех" в dvcs. Ты имеешь в виду "после полной синхронизации всего между парой репозиториев"?
Все участники команды делают push в один репозиторий (любой), а потом все делают pull из него. ) Получаем синхронизированное состояние всей команды в этот момент времени. Естественно при использование DVCS в этом нет надобности, но для проверки одинаковости отображения каждого репозитория вполне подходит. )
_>>3. В Git у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом у каждого репозиторий выглядит по разному (разные имена веток соответствую разным реальным ревизиям и т.д.). ·>Неверно. Имена веток совпадают. Ремотные ветки имеют то же имя что и ветки в ремотном репо. Другое дело, что при необходимости их _можно_ замапить под другим именем на локальные.
Ну так а разработка то идёт в других ветках с другими именами. Ну и к тому же имя Петя/develop вовсе не совпадает с именем develop (не говоря уже о том, что у тебя есть своя ветка develop с совсем другими данными).
Здравствуйте, alex_public, Вы писали:
_>Трудно читать на украинском) Хотя смысл угадывается конечно. )))
Если ты не в Китае или ещё каком медвежьем углу, есть Google Translate. Навязывать свой вариант перевода я не хотел.
_>Из существенных претензий тут только пункт с close-branch. Если бы он был правдивый (тут уже вроде всё показали на эту тему).
Не-а. Из существенных тут невозможность узнать в любой момент, что в staging. Вот это действительно очень серьёзный злобный фактор. А работа веток, которые не ветки, тут действительно мелкий фактор.
_>А чем по твоему отличаются расширения входящие в поставку Mercurial от обычных команд? ) Лично я не вижу вообще никакой разницы.
Тем, что их ещё включать надо. Значит, авторы считают, что по умолчанию они не нужны. А это как раз показывает, на какой вариант они сами рассчитывают и что пропагандируют. Если возможность изменить уже зафиксированный коммит это для них что-то необычное, то это не нормальная работа, а грязнокодинг.
N>>2. Диверсии в виде неименованных голов, наоборот, вынести в расширения и не включать по умолчанию. _>Как ты себе представляешь отключение по умолчанию базовой функциональности, вокруг которой и строится вся система? )))
Она не базовая. Базовая это цепочки коммитов. А фиксация безымянных голов это уже расширение. И это ещё раз показывает следствия безумного бардака с терминологией.
_>Возможно допилят (я же говорю, что технические возможности систем сходятся постепенно). Хотя лично я и все мои окружающие вообще не пользуются командой record, даже в таком виде. Собственно большинство вообще из IDE работает, где это всё неактуально.
IDE не рассматриваем тут принципиально.
N>>4. Решить остальные описанные Lyubomyr Shaydariv проблемы. Для начала, _>Причём тут изменение хэша ревизии? ) Я вообще про другое говорил. Что предпочитаю подход в котором всё, что попадает в систему контроля версий, уже навсегда остаётся в истории.
Это называется наплевательством на качество результата. Я не могу принять ни такой стиль, ни следствия в виде "нефиг менять, раз однажды закоммитил" для *VCS.
Здравствуйте, alex_public, Вы писали:
_>>>Не, команды по определению имеющие дело с одной ревизией только их и принимают (а не имена ссылок/закладки/теги и т.п.). N>>А зачем тогда эти ярлыки используются? Только для чтения истории "под какой ярлык была эта ревизия"? Из пушки по воробьям. _>Так есть же множество команд работающих с наборами ревизий) Там и push/pull/bundle/clone и incoming/outgoing и log и т.д. и т.п.
Очень радует идея представить себе, как, например, log показывает последовательность коммитов совершенно разных веток в одну линию.
_>Т.е. чтобы сделать аналог простейшего режима работы в Mercurial вообще без именованных веток в Git надо завести в каждом репозитории минимум 2 ветки (одну общую для синхронизации и слияний и одну для локальной разработки), правильно? )
Да. И это правильно.
_>>>Какие мысленные усилия? ) Если предположим (для упрощения объяснения) в данной разработке не нужны долгоживущие отдельные ветки (которые по смыслу создаются, а не для синхронизации отдельных членов команды), то в Mercurial будет просто ровно одна ветка периодически разветвляющаяся (в моменты параллельной разработки членов команды) и тут же сливающаяся в одну. _>>>А что будет в случае в Git? ) N>>То же самое. _>Ну покажи пример такого графа. )
Он совпадает с точностью до пометок на коммитах. Не вижу смысла тратиться на рисование примера.
_>P.S. Кстати, тут что-то вспомнилось... А что у git с аналогами команд hg copy/rename/remove? ) Помнится он там что-то автоматическое пытался делать, но чаще всего криво... )))
Здравствуйте, woah, Вы писали:
N>>Слушай, а у тебя с RAM, шиной и т.п. на данном компе всё в порядке? N>>Ничем иным я объяснить подобные чудеса на сейчас не могу, кроме как битым железом.
W>Скорее всего crlf настройки разные стоят у разных членов команды.
Ситуацию, когда в пределах одной рабочей копии status показывает изменение, а hard reset его не сбрасывает, это не даст.
W>Боянная проблема гитоводов.
Боянное верхоглядское делание выводов на основании недочтения с твоей стороны. Или покажи живой пример.
Здравствуйте, woah, Вы писали:
N>>Если авторы не в состоянии отработать с точки зрения даже простейший сценарий использования, как можно предлагать использовать их творение?
W>Резюмирую твои проблемы и вопросы: ты просто не прочитал документацию
Именно, что я её прочитал, и в этом была ошибка. Потому что чтобы понять бред с "ветка — это не ветка, это другая ветка", надо было не читать документацию, в которой это ясно не описано, а надо было начинать с поясняющих источников от тех, кто уже потоптался по этим граблям. И только после этого, уяснив грабли наперекор всему тому, что говорится в документации и туториалах, и прошлому опыту (у меня CVS и SVN), можно начинать "работать" с ним.
"Минус" за необоснованный личный наезд.
W>Гит в этом плане еще хуже, там нормально пользоваться нельзя пока ты досконально не прочитаешь хотя бы git-scm book.
Я не читал никакую git-scm book до начала его использования. Более того, я и сейчас не знаю, что это. Я прочитал двухстраничное руководство по основным сценариям (не помню, как звалось), страничку Git Daily и взял у коллеги распечатку Git Cheat Sheet. Этого хватило для полноценной работы до тех пор, пока не потребовалось корректировать свои глупости в коммитах, для чего был внимательно вкурен git help rebase. После этого потребовалось ещё только несколько раз перечитывать инструкции по конкретным командам. В целом, я не видел ещё более лёгкой в освоении системы. Даже CVS был немного сложнее (хотя тут, возможно, сказалось таки, что это мне была вообще первая система контроля версий).
W>Вообще то что по использованию гита книги пишут уже хороший показатель "удобства" инструмента.
Нет. То, что по нему пишут книги, всего лишь показывает его популярность. Книги писали по всем популярным VCS, начиная с CVS. О любом подобном средстве можно написать книгу, причём в десятках разных стилей — от краткого справочника до полного описания всего, что может встретиться на практике, причём 90% этого будет вообще не зависеть от применяемого средства. Уж поверь автору пары учебных курсов с реальным опытом преподавания.
W>Тот же svn я пользовал из под гуя несколько лет и только пару раз заглядывал в документацию. Просто не было необходимости такой. По гиту то и дело лезу то на стек, то в handbook, то в гугл.
"Из-под гуя" ты пользовал не SVN, а его гуёвую морду, если уж на то пошло. И если ты используешь Git в том же стиле, что SVN, то проблемы не с Git.
Морды вроде Tortoise* универсализуют подходы всех систем (у меня есть коллеги, которые привыкли к SVN и не знают, что его родные средства не позволяют, например, банальный частичный коммит изменений файла). Но это не сами описываемые средства, а нашлёпки.
Здравствуйте, alex_public, Вы писали:
_>>>Хехе, а если взглянуть на это с точки зрения нашей дискуссии.. Ты в курсе наличие в Mercurial команд copy/rename/remove? ))) _>·>Ага, круто, конечно, сразу видно, Бритва тупая попалась. Но как оно поможет разделить один файл на два новых?
_>Эм, ну вообще то даже без всяких VCS, разделение обычно производят через копирование файла и потом стирания в каждой копии ненужного. )))
Именно в таком варианте в анализаторе истории будет обнаружено полное совпадение файла и показан факт копирования.
Но этот метод полезен только для того, чтобы помочь с автослежением по истории.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>Думаю тут наоборот — одна из причин популярности GitHub, в том что он именно GitHub.
НС>А почему тогда слился битбакет, где и гит, и меркьюриал, на выбор?
В каком смысле "слился"? Вчера я с него pull'ил, сейчас зашёл на веб — работает.
Какие проблемы могут быть с публичным сервисом, который зарабатывает на платных версиях сервиса и косвенных источниках — да любые. Вон сейчас GitHub "перетрахивают" ((c) Бацька). Но я подозреваю, что большинство из тех, кто размещают репозитории типа "скрипт для слежения за моей собакой", пугаются фактора "бесплатность до 5 участников", даже когда количество участников не превосходит 3, включая саму собаку.
Здравствуйте, Mazenrab, Вы писали:
M>·>Да нет такой проблемы, открой для себя "git log -M" или ещё круче — "git blame -C", который может найти, например, перемещённый метод из одного файла в другой (такого в hg вроде нет). M>Спасибо, попробую при случае. Но я вообще стараюсь пользоваться встроенным в студию инструментарием полагая что так сложнее выстрелить себе в ногу.
Безотносительно git, зачем навязывать себе искусственные рамки вроде использования только инструментария Студии?
Здравствуйте, alex_public, Вы писали: _>·>Как ты branch переделаешь в bookmark? _>·>Ты говоришь, мол это для короткоживущих, это для долгоживущих... Как ты это определяешь? Ты знаешь будущее? Я не ясновидец, я не умею и не хочу думать об этом выборе. Почему это должно отличаться? _>Зачем переделывать одно в другое? ) Они же все совместимы между собой. Собственно их так обычно и используют. Вот нужна тебе долгоживущая ветка — устанавливаешь имя. Требуется мелкое ответвление в ней — используешь анонимные ветки (правда в данном случае они на самом деле будут не анонимные, а просто с совпадающими именами изначальной). Хочешь как-то выделить одну из этих анонимных подветок — ставишь на неё закладку. ) В общем всё полностью совместимо на любом уровне.
Опять. Почему меня должно волновать долго ли, коротко ли живёт ветка? Зачем меня ставить перед этим выбором? Какую пользу приносит это решение? _>>>·>Расхождение должно появиться только в том случае, если я внёс изменение и в release_candidate, и в default, т.е. появилась ревизия с двумя детьми. А что собственно значит появилось расхождение — это значит, что появилась "альтернативная история", которую можно 3-way мержить. _>>>Ммм, так а ты объясни тогда зачем в твоём сценарии создавать новую ветку и делать в ней пустую ревизию? _>·>А разве можно запушить ветку, если она не закоммичена? _>А что значит "запушить ветку"? ) И зачем это надо? )
Опубликовать в удалённый репозиторий, или, что аналогично, затащить (fetch) из удалённого. Чтобы передать знание о том, что я решил считать релиз-кандидатом. _>·>Не знаю откуда ты берёшь это "формально", в официальной документации это называется named branch, "именованная ветка". Да и команды, работающие с ними "hg branch", "hg branches". "--branch". _>Да, имена команд тоже неудачно вышли, хотя понятно что это так для краткости. Но тут вообще непонятно как было правильно назвать.
Ну "label", ну "tally", например. Или, как в gerrit — "topic". Ещё более кратко — на одну букву короче, а смысла на порядки больше. _>Смотри, тут есть: _>- ветки. Это которые мы в данной дискуссии называем анонимными (хотя на самом деле это неверно, т.к. у любой из них на самом деле есть имя (default или какое-то другое), просто оно может совпадать с именем соседней ветки). _>- имена веток. Просто атрибут у каждой ревизии.
Жуткий бардак в терминологии, Оккама не позвали. _>Так вот команды hg branch и т.п. работают как раз с именами веток, так что теоретически должны были бы называться как-то типа branch_name и т.п. Но это же тоже бредово... )
Бредово, т.к. с твоей верой не согласуется... _>·>Я не понимаю что ты подразумеваешь под нормально работать. Зачем вообще с анонимными ветками работать? Особенно в случае, если с именованными проблем никаких. _>Это уже отдельный вопрос (который мы вроде как тоже параллельно обсуждаем). Но вне зависимости от его результатов у нас останется тот факт, что в Git отсутствует имеющаяся в Mercurial возможность работы с анонимными ветками.
Она отсутствует, т.к. не нужна, не существует сценариев работы, которые дадут анонимную ветку. Если бы кому-то была нужна, добавили бы, т.к. элементарно. _>·>Эти проблемы, надеюсь, уже пофиксили? _>Хы, к mercurial там ровно две претензии: _>1. не позволяет подчищать репозиторий задним числом без особых манипуляций. Смешно, т.к. сохранности историй — это один из базовых принципов Mercurial.
Это базовый принцип CVCS, для DVCS этот принцип выражается как "receive.denyNonFastForwards". _>2. не позволяет сделать push закладки. Видимо автор не в курсе про параметр -B у команды push. )))
Ок, значит пофиксили. Хорошо. Если придётся использовать hg, буду использовать только букмарки. _>>>Собственно я ещё в самом начале дискуссии сказал, что данный вопрос больше дело вкуса. ) _>·>Хорошо, пусть дело вкуса. Но смысла уж точно нет. _>Вот не надо только пропагандировать тут подход Apple — в профессиональной среде он плохо проходит. )))
Вроде ты тут пропагандируешь — смысла нет, остаётся только дело вкуса. _>·>Не понял. В каком начале? Это текущий граф, текущая история. sequence может быть выражена как последовательность точек. Я поменял граф, обозначив точки уникально. Перечисли эти линии. _>Я так и не понял что ты хочешь))) Точнее не пойму чем тебя не устраивает мой ответ в первом же сообщение (много страниц назад). Ну да ладно, мне не сложно повторить в сотый раз, уже с буковками. ))) Последовательности ревизий: {a, b, c}, {d, e, f}, {g}, {h, i, j, k}.
Ок, допустим. Ты говорил, что последовательность ревизий это и есть ветка. Ты говорил, что hg позволяет хорошо работать с ветакми. Какой командой мне вывести эти четыре ветки для этого графа истории? _>·>В hg об Оккаме и не всмоминали: помимо "именованных веток" ввели сущность "анонимные ветки" и прочие закладки с головами. _>·>Мне вообще интересно, опиши сценарий: откуда в git появится ревизия на которую нет ссылкок и что ты с ней хочешь делать, для чего она тебе может понадобится? _>Ну вот работаю над каким-то проектом, решил проверить некое решение, закодировал, убедился что оно сейчас не подходит (но код полезный и пригодится в будущем), зафиксировал его в виде ревизии, откатился назад на одну ревизий и пошёл работать дальше, создавая новые ревизии. При этом у меня там
останется маленький отросток (ветка из одной ревизии), который возможно когда-нибудь пригодится. _>Это я описал сценарий в Mercurial. А как оно будет в Git? ) Будешь создавать по каждому такому поводу отдельную ветку с новым именем? )
Конечно, в гите будет всё очень сложно. Поместил под кат длинный скрипт, чтобы не делать сообщение чрезвычайно очень длинным.
Тут этот офигительно сложный скрипт, который доступен только после двадцатилетних курсов изучения гит фулл-тайм на специальных платных курсах, дарю тебе бесплатно
git stash
Неужели в hg так нельзя?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>В каком смысле "слился"?
В смысле что на первых порах они с гитхабом активно конкурировали и были примерно одного уровня популярности. Но потом гитхабовцы их переплюнули за счет активного добавления новых фич. Битбакет задергался, но поезд уже ушел, и сейчас сравнивать их популярность просто смешно.
Здравствуйте, alex_public, Вы писали:
_>>>2. В Mercurial у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом в синхронизированном состояние она у всех одинаковая. _>·>Враньё же... Показывали же тут эти картинки — выглядят по-разному, т.к. корёжатся локальными номерами ревизий. _>Это типа юмор? ))) Тогда уж у разных участников команды возможно ещё и разные GUI к Mercurial и там уж точно по разному деревья рисуются... )))
Интересно посмотреть консольный граф, чтобы выглядел одинаково.
_>·>Ещё интересно, что же такое "синхронизованное состояние у всех" в dvcs. Ты имеешь в виду "после полной синхронизации всего между парой репозиториев"? _>Все участники команды делают push в один репозиторий (любой), а потом все делают pull из него. ) Получаем синхронизированное состояние всей команды в этот момент времени. Естественно при использование DVCS в этом нет надобности, но для проверки одинаковости отображения каждого репозитория вполне подходит. )
Т.е. сценарий CVCS. В такой ситуации графы git будут совпадать с точностью до буковки.
_>>>3. В Git у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом у каждого репозиторий выглядит по разному (разные имена веток соответствую разным реальным ревизиям и т.д.). _>·>Неверно. Имена веток совпадают. Ремотные ветки имеют то же имя что и ветки в ремотном репо. Другое дело, что при необходимости их _можно_ замапить под другим именем на локальные. _>Ну так а разработка то идёт в других ветках с другими именами. Ну и к тому же имя Петя/develop вовсе не совпадает с именем develop (не говоря уже о том, что у тебя есть своя ветка develop с совсем другими данными).
Имя совпадает, это "develop", а "Петя/" это префикс или пространство (namespace). Т.е. имена не глобальны, а разделены на пространства естественным образом.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
_>>Трудно читать на украинском) Хотя смысл угадывается конечно. ))) N>Если ты не в Китае или ещё каком медвежьем углу, есть Google Translate. Навязывать свой вариант перевода я не хотел.
Хы, точно, как-то я не подумал. ) Видимо он всё же не как иностранный ощущается. )))
_>>Из существенных претензий тут только пункт с close-branch. Если бы он был правдивый (тут уже вроде всё показали на эту тему). N>Не-а. Из существенных тут невозможность узнать в любой момент, что в staging. Вот это действительно очень серьёзный злобный фактор. А работа веток, которые не ветки, тут действительно мелкий фактор.
Это ты про что (в Mercurial же нет понятия staging), про возможность показать что будет зафиксировано или про какие-то дополнения к работе расширения record? )
_>>А чем по твоему отличаются расширения входящие в поставку Mercurial от обычных команд? ) Лично я не вижу вообще никакой разницы. N>Тем, что их ещё включать надо. Значит, авторы считают, что по умолчанию они не нужны. А это как раз показывает, на какой вариант они сами рассчитывают и что пропагандируют. Если возможность изменить уже зафиксированный коммит это для них что-то необычное, то это не нормальная работа, а грязнокодинг.
Всё верно. Режим по умолчанию рекомендует не трогать историю, а если уж очень хочется, то можешь включить в расширениях.
А почему это грязнокодинг? ) Разве нельзя добиться нужного результата не меняя историю (например та же команда hg backout демонстрирует пример подобного)? В итоге у тебя будет всё красиво и история сохранится. Или тебе надо скрыть из истории все следы косяков и т.п.? )))
N>>>2. Диверсии в виде неименованных голов, наоборот, вынести в расширения и не включать по умолчанию. _>>Как ты себе представляешь отключение по умолчанию базовой функциональности, вокруг которой и строится вся система? ))) N>Она не базовая. Базовая это цепочки коммитов. А фиксация безымянных голов это уже расширение. И это ещё раз показывает следствия безумного бардака с терминологией.
А как можно организовать цепочки без фиксации? )
N>>>4. Решить остальные описанные Lyubomyr Shaydariv проблемы. Для начала, _>Причём тут изменение хэша ревизии? ) Я вообще про другое говорил. Что предпочитаю подход в котором всё, что попадает в систему контроля версий, уже навсегда остаётся в истории. N>Это называется наплевательством на качество результата. Я не могу принять ни такой стиль, ни следствия в виде "нефиг менять, раз однажды закоммитил" для *VCS.
А что ты называешь качественным результатом то? ) Мне казалось это должна быть идеально работающая последняя ревизия. Но у тебя это похоже что-то иное... )))
Здравствуйте, netch80, Вы писали:
_>>Т.е. чтобы сделать аналог простейшего режима работы в Mercurial вообще без именованных веток в Git надо завести в каждом репозитории минимум 2 ветки (одну общую для синхронизации и слияний и одну для локальной разработки), правильно? ) N>Да. И это правильно.
Ага, и в итоге у каждого репозиторий выглядит по своему. Весело. )))
_>>P.S. Кстати, тут что-то вспомнилось... А что у git с аналогами команд hg copy/rename/remove? ) Помнится он там что-то автоматическое пытался делать, но чаще всего криво... ))) N>Не понимаю проблемы.
Да тут вот народ рядом жалуется на то, что при рефакторинге git делает некую ересь. )
Здравствуйте, netch80, Вы писали:
_>>Эм, ну вообще то даже без всяких VCS, разделение обычно производят через копирование файла и потом стирания в каждой копии ненужного. ))) N>Именно в таком варианте в анализаторе истории будет обнаружено полное совпадение файла и показан факт копирования. N>Но этот метод полезен только для того, чтобы помочь с автослежением по истории.
Это только если зафиксировать изменения сразу после копирования. А если закончить рефакторинг до конца, то что тогда будет? )
Здравствуйте, ·, Вы писали: _>>Зачем переделывать одно в другое? ) Они же все совместимы между собой. Собственно их так обычно и используют. Вот нужна тебе долгоживущая ветка — устанавливаешь имя. Требуется мелкое ответвление в ней — используешь анонимные ветки (правда в данном случае они на самом деле будут не анонимные, а просто с совпадающими именами изначальной). Хочешь как-то выделить одну из этих анонимных подветок — ставишь на неё закладку. ) В общем всё полностью совместимо на любом уровне. ·>Опять. Почему меня должно волновать долго ли, коротко ли живёт ветка? Зачем меня ставить перед этим выбором? Какую пользу приносит это решение?
Я тебе описал наиболее продуманные решения. Но тебя никто не заставляет ими пользоваться. Может приделывать имя на каждое микроветвление или вести основные ветки через закладки. Делай как тебе нравится. ))) _>>А что значит "запушить ветку"? ) И зачем это надо? ) ·>Опубликовать в удалённый репозиторий, или, что аналогично, затащить (fetch) из удалённого. Чтобы передать знание о том, что я решил считать релиз-кандидатом.
Эм, т.е. ты снова пытаешься просто повесить некую метку на конкретную ревизию с помощью создания именованной ветки? ) Жесть, вот что привычки к git'у делают. ))) _>>Так вот команды hg branch и т.п. работают как раз с именами веток, так что теоретически должны были бы называться как-то типа branch_name и т.п. Но это же тоже бредово... ) ·>Бредово, т.к. с твоей верой не согласуется...
Бредово в том смысле что длинно и неудобно, хотя и верно по смыслу) _>>Вот не надо только пропагандировать тут подход Apple — в профессиональной среде он плохо проходит. ))) ·>Вроде ты тут пропагандируешь — смысла нет, остаётся только дело вкуса.
Не, подход Apple "у нас этого нет — значит оно вам не нужно". ))) _>>Я так и не понял что ты хочешь))) Точнее не пойму чем тебя не устраивает мой ответ в первом же сообщение (много страниц назад). Ну да ладно, мне не сложно повторить в сотый раз, уже с буковками. ))) Последовательности ревизий: {a, b, c}, {d, e, f}, {g}, {h, i, j, k}. ·>Ок, допустим. Ты говорил, что последовательность ревизий это и есть ветка. Ты говорил, что hg позволяет хорошо работать с ветакми. Какой командой мне вывести эти четыре ветки для этого графа истории?
Так это смотря в какой момент времени смотреть) В разные моменты будут разные ответы. ) _>>Ну вот работаю над каким-то проектом, решил проверить некое решение, закодировал, убедился что оно сейчас не подходит (но код полезный и пригодится в будущем), зафиксировал его в виде ревизии, откатился назад на одну ревизий и пошёл работать дальше, создавая новые ревизии. При этом у меня там ·>останется маленький отросток (ветка из одной ревизии), который возможно когда-нибудь пригодится. _>>Это я описал сценарий в Mercurial. А как оно будет в Git? ) Будешь создавать по каждому такому поводу отдельную ветку с новым именем? ) ·>Конечно, в гите будет всё очень сложно. Поместил под кат длинный скрипт, чтобы не делать сообщение чрезвычайно очень длинным. ·>
Тут этот офигительно сложный скрипт, который доступен только после двадцатилетних курсов изучения гит фулл-тайм на специальных платных курсах, дарю тебе бесплатно
·>git stash
·>Неужели в hg так нельзя?
Так можно (это будет hg shelve), но это даже не близко к тому, что я описал. Как мне к примеру воспользоваться этим кодом из соседнего репозитория? ) Я уже не говорю о том, чтобы посмотреть разницу с текущей копией и т.п.
Здравствуйте, ·, Вы писали:
_>>·>Ещё интересно, что же такое "синхронизованное состояние у всех" в dvcs. Ты имеешь в виду "после полной синхронизации всего между парой репозиториев"? _>>Все участники команды делают push в один репозиторий (любой), а потом все делают pull из него. ) Получаем синхронизированное состояние всей команды в этот момент времени. Естественно при использование DVCS в этом нет надобности, но для проверки одинаковости отображения каждого репозитория вполне подходит. ) ·>Т.е. сценарий CVCS. В такой ситуации графы git будут совпадать с точностью до буковки.
Не будут — см. ниже)
_>>Ну так а разработка то идёт в других ветках с другими именами. Ну и к тому же имя Петя/develop вовсе не совпадает с именем develop (не говоря уже о том, что у тебя есть своя ветка develop с совсем другими данными). ·>Имя совпадает, это "develop", а "Петя/" это префикс или пространство (namespace). Т.е. имена не глобальны, а разделены на пространства естественным образом.
Так, я сажусь за один компьютер даю команду показать мне содержимое ветки develop. Потом сажусь за соседний, даю такую же команду и вижу другие данные. Это ты называешь одинаковыми репозиториями? )))
