Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, D.Lans, Вы писали:
DL>>Хайпа вокруг гита не понимаю. Ладно самое красноглазное подмножество линуксоидов-ядерщиков в своём мирке юзают что им удобнее (белоглазые же линуксоиды, я слышал, почётно восседают на bazaar), но гит с хрустом начинают жевать маководы и виндузятники (к коим отношусь и я), с улыбкой гарольда-скрывающего-боль нахваливая и зазывая всех присоединиться к их клёвым проектам, худо-бедно выложенным на модный нынче гитхаб (но которые почему-то так и не получают должной популярности), я в недоумении развожу руками. C>ЩИТО? Откуда вы такую траву взяли?
C>Я не понимаю сторонников hg. Они массово не понимают как вообще работают DVCS. Git вообще тупой как пробка, там сложного нет ничего. Банально достаточно запомнить, что коммиты образуют цепочку хэшей и всё.
C>Достаточно уметь это понимать, и всё в git становится понятным.
Надо еще понимать, что есть локальный репозиторий, а не только удаленный.
Здравствуйте, alex_public, Вы писали:
_>>>Текущая ревизия — это понятие глобальное на все файлы, т.е. относится к хранилищу. N>>Оно не относится к хранилищу. Оно относится к состоянию рабочей копии. Хранилище при этом не меняется, как бы я ни двигал, какой именно коммит текущий выбранный. _>И где в рабочей копии по твоему тогда хранится информация о том, к какой ревизии она относится? )
Вот именно что ты в принципе думаешь о том, "где хранится". А пользователю это пофиг, он думает о том, с чем он работает, и концепции должны быть связаны именно этим. Если исходить из текущего построения, 1) оно может меняться, 2) каждое такое несоответствие означает один дополнительный ненужный факт для запоминания.
Иногда эти странности прилипают, и мы имеем "compiler" для конвертера в машинный код (вместо редактора связей), "virtual" ровно противоположное бытовому пониманию, и т.п. Но незачем порождать новые такие диверсии.
_>>>P.S. Что-то ты в этой темке прямо разошёлся (хотя ничего по делу я так и не увидел, правда и не рассчитывал: выбор между git и mercurial — это реально дело вкуса), N>>Когда (см. соседнее сообщение) меня какая-то тулза заставляет переопределить давно устоявшиеся, стандартные по отрасли понятия — это уже не обычное дело вкуса, это bdsm.
_>С чего ты взял, что давно устоявшиеся? ) Git/Mercurial/Bazaar родились в принципе одновременно и все три могут претендовать на основоположников терминологии.
То есть, по-твоему, до этих трёх ничего не было и никаких традиций не было? Родились на пустом месте?
Даже если ограничиться DVCS:
* BitKeeper (2000) — первая шумно известная DVCS, заложившая основы всего подхода.
* Tom Lord's Arch (позднее GNU Arch) (2001), первая opensource — дико громоздкая, неудобная, но доступная и показавшая возможность в принципе.
* Darcs (2002) — не взлетевшая толком, но знаменитая математическим подходом к "алгебре патчей" и давшая идеи для построения всех последующих.
* Monotone (2003) — второй после BitKeeper предшественник Git и источник его идей, место отработки подходов.
Git не был ничем новым — это был идейный гибрид BitKeeper и Monotone по уже отработанным сценариям.
Правильно пел когда-то Макаревич, что помнят не первых, а вторых, но в этом случае оказывается даже не вторых, а третьих.
Но что-то я ни у одной из этих систем не помню такого извращённого подхода к понятию "ветка". А учитывая, что большинство в это время только переходили с CVS и аналогов, считать надо по их опыту и соответствию общим концепциям мышления, а не "мы тут выстебнулись — а ну все подвинулись".
_> Если же говорить о реально устоявшихся, то это будет скорее SVN и более старые системы — как думаешь, к какой из DVCS их терминология будет ближе? )
К Git, если брать CVS. Вообще ни к чему из них, если брать SVN и учитывать варианты "скопировали в /release/foo весь /trunk, но в /release/foo/zuka скопировали /releng/bar/zuka". Но если не учитывать их — то SVN ближе к CVS и Git, чем к Hg, потому что нет действия типа "сегодня веткой X будет называться каталог Y". Вот если бы они ввели симлинки и назвали их ветками — было бы хоть как-то похоже.
Здравствуйте, alex_public, Вы писали:
_>>>Разная идеология понятия "ветка". N>>Вот я _обожаю_ такие высказывания. Как только возникают вопросы про конкретные особенности веток — начинаются рассказы про "идеологию". "У нас тут своя атмосфера", видите ли. При этом ничего конкретного по сути вопроса не говорится, ссылка на идеологию всё спишет. _>Разница очевидна. В git ветка — это что-то временное, а в mercurial ветки остаются навсегда в истории.
Не ветки. А их имена на момент коммита. Правильное называние сущностей помогает их правильному пониманию (вольное переложение Конфуция).
N>>Хорошо видно, что "branch: x1" написано на двух коммитах из разных веток (цепочек из коммитов, a.k.a. changeset'ов)? Простите, это из какой такой идеологии "бранчем" именуется нечто, что может перескочить между реальными ветками разработки? Теперь ветки — это не те ветки, а не те ветки — это ветки?
_>Покажи к чему приведут аналогичные действия в git'e и мы вместе посмеёмся. )))
Такой ситуации просто не возникнет. А если ты решишь вписать неадекватное имя ветки вручную в коммит — что ж, это было твоё решение.
_>О, кстати, ещё один практический нюанс вспомнился... Работа с автоматическими анонимными ветками намного удобнее в Mercurial. Собственно не помню как вообще в Git с ними работать (скажем аналог команды heads?).
Опиши желаемое подробнее, не понимаю.
_>>>Ну вообще то я говорил не про набор хуков, а про удобство расширения. Но даже если говорить про набор, то помнится в git'е раньше не было многих. Например preoutgoing и т.п. Сейчас не знаю, не смотрел, может и добавили. N>>Почитал про preoutgoing. Смысла не понял. Заодно прочёл, что в нём ничего не известно и что он не зовётся при push, хотя зовётся при передаче в другое репо. Какая-то совсем вещь в себе, или опять та трава, которая не та трава. _>Полезно для создания нестандартных каналов передачи (скажем с шифрованием и т.п.).
В Git банально переопределяется команда связи.
_>>>По умолчанию фиксируются все модифицированные файлы и это намного удобнее (т.к. это самый частый вариант использования), чем каждый раз писать "-a". Если надо зафиксировать изменение не всех файлов, то точно так же как и в git передаётся список в команду commit. Лично я же в таком случае предпочитаю снимать галочки в TortoiseHg. ))) N>>А часть одного файла? _>Эээ, что что? )
Я занимаюсь лечением бага. Для его диагностики вставлено 6 мест отладочной печати. Затем вписано 4 исправления собственно этого бага, причём 2 из них на рефакторинг "выделить код в отдельный метод" и 2 на исправление ошибки. Всё это в одном файле.
Мне нужно создать 2 коммита — рефакторинг и исправление — и оставить отладочную печать на несколько дней, пока не завершится, грубо говоря, весь деплоймент.
Git даёт сразу несколько методов набирать только те патчи из всех изменений, которые нужны для текущего коммита.
Ни в одной другой VCS я такого не видел. Врапперы во всяких IDE не учитывать.
_>>>Да, что касается формального сравнения разных команд... Я никогда об этом специально не задумывался, просто интуитивно чувствуется удобство в определённых случаях (потому и говорю что дело вкуса). Но вот сейчас решил чуть задуматься. Как там в git'e скажем насчёт аналога команды hg incoming? N>>Делается через fetch+diff. А какой смысл в команде в таком виде, как в hg? На каждый вызов выкачивать список изменений, показывать их, но не сохранять локально? А если два вызова, оно в состоянии это закэшировать? Юзкейс совершенно непонятен. _>Смысл в том, что просматриваемые изменения не попадают в твой репозиторий. Конечно можно потом извратиться и выкинуть их оттуда, но это уже лишние сложности.
OK, хотя и не понимаю практическую важность ситуации.
N>>И пока что я вижу в hg в основном такие хохмы. "Ветки", которые не ветки. "Закладки", которые тем не менее держат на себе состояние репо, хотя по смыслу названия они должны быть просто тегами. Команды с непонятным юзкейсом и заведомо неэффективным стилем исполнения. Зачем всё это? _>Да да, вот у меня такое же впечатление от git. ) Вроде как вся базовая функциональность имеется, но всё как-то через задницу. )
Как раз соответственно проверенным концепциям и подходам.
Здравствуйте, Sharov, Вы писали:
C>>Я не понимаю сторонников hg. Они массово не понимают как вообще работают DVCS. Git вообще тупой как пробка, там сложного нет ничего. Банально достаточно запомнить, что коммиты образуют цепочку хэшей и всё. C>>Достаточно уметь это понимать, и всё в git становится понятным. S>Надо еще понимать, что есть локальный репозиторий, а не только удаленный.
Ну это как раз пишется в руководствах первым же пунктом (и это то, что меня от DVCS воротило некоторое начальное время — держать репо там же, где рабочая копия, казалось дико неестественным).
Здравствуйте, alex_public, Вы писали:
_>>>- заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs. _>·>Верно, дело вкуса. Результат отказа от традиционной идеологии. _>Эмм, а что значит традиционная идеология в данном случае?
hg многое унаследовал от svn, svn от cvs, а git делался без особой оглядки на существующие системы, а полагался на собственную архитектуру. Поэтому всё так непривычно.
_>>>Это смотря на каком уровне смотреть. Формально да, одно хранит дифы, а другое вроде как сами файлы. Но фокус в том, что если бы оно реально хранило сами файлы, то размер хранилища был бы нереальным. Так что в итоге и второе хранит дифы, просто они там для сжатия, а не для идеологии. _>·>Правильно, SRP применён — хранение абстрагировано от представления, что облегчает многие фичи. И, кстати, даёт больше возможностей для оптимизации сжатия. _>Однако на практике получается наоборот. Попробуй сравнить размеры хранилищ и размеры пакетов (которые bundle — самый удобный способ сравнить необходимый объём данных для синхронизации по сети) git и mercurial для одинаковых репозиториев. )
Не очень понял, как именно сравнить? Да и собственно даже если есть и отличие (кстати, сильно не уверен, что в пользу hg), вряд ли оно будет заметно. Даже передача тысяч ревизий занимает секунды...
_>Кстати, помнится видел разные вроде как тесты (почему-то публикуемые на kernel.org — какое совпадение ), в которых git сильно выигрывает в размере репозитория у своих конкурентов. Правда там мелким шрифтом приписано, что это тестируется после применения repack в git. ))) Ну т.е. если мы после каждого изменения будем делать repack, то тогда git действительно всех обойдёт (правда советую в начале глянуть сколько времени оно занимает). А вот если взглянуть на реальность, то... )))
...то в реальности делать repack после каждого изменения — глупость.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Dair, Вы писали:
D>Консольный Git, 2.6.0
Уже проапгрейдился, гит теперь последний, 2.7.0.
Опять круто.
Диспозиция: я в своей ветке, наменял разного, делаю коммит (не push) и готовлюсь взять последюю версию от коллег из develop, чтобы не сильно отставать. Для этого надо мне тут сделать commit, переключиться на общий develop, сделать pull, переключиться обратно, сделать merge. Делаю:
$ git commit -a
...
$ git status
нечего коммитить, нет изменений в рабочем каталоге
$ git checkout develop
Распаковка файлов: 100% (2618/2618), готово.
Переключено на ветку «develop»
Ваша ветка обновлена в соответствии с «origin/develop».
$ git pull
...
Обновление 0990c58..b4a4250
...
(в общем, success)
$ git checkout feature/my_cool_branch
error: Your local changes to the following files would be overwritten by checkout:
some/path/file1.cpp
some/path/file2.cpp
some/path/file3.cpp
some/path/file4.cpp
some/path/file5.cpp
...
Здравствуйте, netch80, Вы писали:
_>>С чего ты взял, что давно устоявшиеся? ) Git/Mercurial/Bazaar родились в принципе одновременно и все три могут претендовать на основоположников терминологии. N>То есть, по-твоему, до этих трёх ничего не было и никаких традиций не было? Родились на пустом месте? N>Даже если ограничиться DVCS: N>* BitKeeper (2000) — первая шумно известная DVCS, заложившая основы всего подхода. N>* Tom Lord's Arch (позднее GNU Arch) (2001), первая opensource — дико громоздкая, неудобная, но доступная и показавшая возможность в принципе. N>* Darcs (2002) — не взлетевшая толком, но знаменитая математическим подходом к "алгебре патчей" и давшая идеи для построения всех последующих. N>* Monotone (2003) — второй после BitKeeper предшественник Git и источник его идей, место отработки подходов. N>Git не был ничем новым — это был идейный гибрид BitKeeper и Monotone по уже отработанным сценариям. N>Правильно пел когда-то Макаревич, что помнят не первых, а вторых, но в этом случае оказывается даже не вторых, а третьих.
Вообще то если уж брать реальную историю, то первой такой системой был не BitKeeper (кстати 1998 год, а не 2000), а некий Code Co-op. Однако это всё не имеет никакого значения, т.к. все эти системы были мало известны и соответственно не могли задавать никаких традиции в индустрии.
N>Но что-то я ни у одной из этих систем не помню такого извращённого подхода к понятию "ветка". А учитывая, что большинство в это время только переходили с CVS и аналогов, считать надо по их опыту и соответствию общим концепциям мышления, а не "мы тут выстебнулись — а ну все подвинулись".
Вообще то понятие ветка в Mercurial точно такое же, как и везде. Если ты не сумел разобраться, то это не значит что там что-то не так. Для начала не плохо бы почитать документацию.
_>> Если же говорить о реально устоявшихся, то это будет скорее SVN и более старые системы — как думаешь, к какой из DVCS их терминология будет ближе? ) N>К Git, если брать CVS. Вообще ни к чему из них, если брать SVN и учитывать варианты "скопировали в /release/foo весь /trunk, но в /release/foo/zuka скопировали /releng/bar/zuka". Но если не учитывать их — то SVN ближе к CVS и Git, чем к Hg, потому что нет действия типа "сегодня веткой X будет называться каталог Y". Вот если бы они ввели симлинки и назвали их ветками — было бы хоть как-то похоже.
Здравствуйте, netch80, Вы писали:
_>>Покажи к чему приведут аналогичные действия в git'e и мы вместе посмеёмся. ))) N>Такой ситуации просто не возникнет. А если ты решишь вписать неадекватное имя ветки вручную в коммит — что ж, это было твоё решение.
Т.е. я правильно понимаю, что при работе с Git рекомендуется не нарушать некие правила, а при работе с Mercurial наоборот? )))
_>>О, кстати, ещё один практический нюанс вспомнился... Работа с автоматическими анонимными ветками намного удобнее в Mercurial. Собственно не помню как вообще в Git с ними работать (скажем аналог команды heads?). N>Опиши желаемое подробнее, не понимаю.
Ну очевидно же) Фиксируем некие изменения, потом откатываемся назад на одну ревизию, снова что-то меняем и снова фиксируем (не создавая новых веток вообще). Кстати, аналогичного можно добиться и проще (как раз более практичный вариант) — фиксация своих изменений несколькими разработчиками в одну и ту же ветку, с последующей синхронизацией.
Что будет в таком случае в git и как с этим удобно работать? )
В Mercurial всё будет крайне удобно и это собственно один из нормальных сценариев работы.
_>>Полезно для создания нестандартных каналов передачи (скажем с шифрованием и т.п.). N>В Git банально переопределяется команда связи.
Ой, вот как раз насчёт удобства расширения в Git я бы вообще помолчал))) Там с API всё настолько печально... )
N>>>А часть одного файла? _>>Эээ, что что? ) N>Я занимаюсь лечением бага. Для его диагностики вставлено 6 мест отладочной печати. Затем вписано 4 исправления собственно этого бага, причём 2 из них на рефакторинг "выделить код в отдельный метод" и 2 на исправление ошибки. Всё это в одном файле. N>Мне нужно создать 2 коммита — рефакторинг и исправление — и оставить отладочную печать на несколько дней, пока не завершится, грубо говоря, весь деплоймент. N>Git даёт сразу несколько методов набирать только те патчи из всех изменений, которые нужны для текущего коммита. N>Ни в одной другой VCS я такого не видел. Врапперы во всяких IDE не учитывать.
Ужасы какие) Как раз для таких дел и создают отдельные ветки (отладочная, релизная и т.п.).
Здравствуйте, Dair, Вы писали:
D>Диспозиция: я в своей ветке, наменял разного, делаю коммит (не push) и готовлюсь взять последюю версию от коллег из develop, чтобы не сильно отставать. Для этого надо мне тут сделать commit, переключиться на общий develop, сделать pull, переключиться обратно, сделать merge. Делаю:
Что-то странные пляски. Зачем переключаться-то? Просто делаешь "git fetch", потом "git merge origin/develop", мержить можно и удалённые ветки.
D>
А что diff показывает?
Чую какая-то беда с line endings
D>Проверил сторонние процессы — никого нет, никто к файлам не доступается.
IDE может нахулиганить
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>·>Верно, дело вкуса. Результат отказа от традиционной идеологии. _>>Эмм, а что значит традиционная идеология в данном случае? ·>hg многое унаследовал от svn, svn от cvs, а git делался без особой оглядки на существующие системы, а полагался на собственную архитектуру. Поэтому всё так непривычно.
противоположное мнение высказывается. )
_>>Однако на практике получается наоборот. Попробуй сравнить размеры хранилищ и размеры пакетов (которые bundle — самый удобный способ сравнить необходимый объём данных для синхронизации по сети) git и mercurial для одинаковых репозиториев. ) ·>Не очень понял, как именно сравнить? Да и собственно даже если есть и отличие (кстати, сильно не уверен, что в пользу hg), вряд ли оно будет заметно. Даже передача тысяч ревизий занимает секунды...
Ну возьми просто один большой (скажем на мегабайт, для простоты эксперимента) и кинь его пустой репозиторий. Ну поменяй пару строк и зафиксируй. И посмотри размер хранилища. Для hg и для git.
Ну а что касается обмена изменениями, то для последних ревизий (где пара строк менялась) разница действительно не принципиальна (типа 100 байт или 200), а вот если взять все ревизии (тогда оно будет включать файлы целиком), то опять же будет весьма интересный результат...
_>>Кстати, помнится видел разные вроде как тесты (почему-то публикуемые на kernel.org — какое совпадение ), в которых git сильно выигрывает в размере репозитория у своих конкурентов. Правда там мелким шрифтом приписано, что это тестируется после применения repack в git. ))) Ну т.е. если мы после каждого изменения будем делать repack, то тогда git действительно всех обойдёт (правда советую в начале глянуть сколько времени оно занимает). А вот если взглянуть на реальность, то... ))) ·>...то в реальности делать repack после каждого изменения — глупость.
Согласен. ) И в таком случае выигрывать по размеру хранилища будет скорее Mercurial.
Здравствуйте, AK107, Вы писали:
AK>Здравствуйте, netch80, Вы писали:
AK>можно с вопросом влезть?
AK>насколько помню, раньше была проблема у гита с одновременным переименованием и изменением файла. это уже починили или все так же? вроде как история "терялась"
AK>я почему интересуюсь, для меня, как C# программера — это базовая операция — переименование класса (class per file).
Здравствуйте, alex_public, Вы писали:
_>·>hg многое унаследовал от svn, svn от cvs, а git делался без особой оглядки на существующие системы, а полагался на собственную архитектуру. Поэтому всё так непривычно. _>Согласен) Хотя вот тут http://rsdn.ru/forum/flame.comp/6335165.1
противоположное мнение высказывается. )
Ну, если более старые DVCS рассматривать, то да. Но накой DVCS hg начала что-то тянуть из centralised VCS типа svn... это не совсем разумное решение. Может в короткой перспективе, перетянуть юзеров, это и хорошо, но лучше в этом болоте не засиживаться.
_>·>Не очень понял, как именно сравнить? Да и собственно даже если есть и отличие (кстати, сильно не уверен, что в пользу hg), вряд ли оно будет заметно. Даже передача тысяч ревизий занимает секунды... _>Ну возьми просто один большой (скажем на мегабайт, для простоты эксперимента) и кинь его пустой репозиторий. Ну поменяй пару строк и зафиксируй. И посмотри размер хранилища. Для hg и для git.
Игрушечных экспериментов, которые плохо сработают для hg я могу тоже насочинять. Например, добавить тот же файл дважды в разные каталоги.
_>Ну а что касается обмена изменениями, то для последних ревизий (где пара строк менялась) разница действительно не принципиальна (типа 100 байт или 200), а вот если взять все ревизии (тогда оно будет включать файлы целиком), то опять же будет весьма интересный результат...
Эээ.. А как ещё? Если хочется патчи, бери патчи.
_>·>...то в реальности делать repack после каждого изменения — глупость. _>Согласен. ) И в таком случае выигрывать по размеру хранилища будет скорее Mercurial.
Будет, но не долго, до первого же repack.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Dair, Вы писали:
D>Диспозиция: я в своей ветке, наменял разного, делаю коммит (не push) и готовлюсь взять последюю версию от коллег из develop, чтобы не сильно отставать. Для этого надо мне тут сделать commit, переключиться на общий develop, сделать pull,
Нафига???
git fetch origin develop:develop
Никак не зависит от текущей ветки, состояния рабочей копии и т.п., если текущая ветка не develop.
D> переключиться обратно, сделать merge. Делаю:
D>$ git reset --hard D>$ git status D>... D> изменено: some/path/file1.cpp D> изменено: some/path/file2.cpp D> изменено: some/path/file3.cpp D> изменено: some/path/file4.cpp D> изменено: some/path/file5.cpp D>... D>[/code]
D>И вот тут я не понимаю что делать.
D>Проверил сторонние процессы — никого нет, никто к файлам не доступается.
Слушай, а у тебя с RAM, шиной и т.п. на данном компе всё в порядке?
Ничем иным я объяснить подобные чудеса на сейчас не могу, кроме как битым железом.
Здравствуйте, alex_public, Вы писали:
_>Вообще то если уж брать реальную историю, то первой такой системой был не BitKeeper (кстати 1998 год, а не 2000), а некий Code Co-op. Однако это всё не имеет никакого значения, т.к. все эти системы были мало известны и соответственно не могли задавать никаких традиции в индустрии.
Во-первых: я тоже далеко не первых назвал, я назвал хорошо известных предыдущих.
Во-вторых, я не знаю, где ты был в этой индустрии в те времена, если ты не заметил, например, шума про то, что Линус, после того, как много лет "по матушке" посылал хотя бы за идею вести разработку или даже публичное репо нумерованных версий в доступных тогда средствах вроде CVS — вдруг разразился "все на BitKeeper!" — шок был весьма существенный.
Я был тогда (как и сейчас) среди активных юниксоедов, подо мной была существенная часть ответственности интернет-провайдера, у нас были линуксы, и за всем этим я пристально следил (находясь на позиции "лучше CVS, чем ничего" — с чем регулярно спорил с активными линуксоманами).
N>>Но что-то я ни у одной из этих систем не помню такого извращённого подхода к понятию "ветка". А учитывая, что большинство в это время только переходили с CVS и аналогов, считать надо по их опыту и соответствию общим концепциям мышления, а не "мы тут выстебнулись — а ну все подвинулись". _>Вообще то понятие ветка в Mercurial точно такое же, как и везде. Если ты не сумел разобраться, то это не значит что там что-то не так. Для начала не плохо бы почитать документацию.
Я почитал, и попробовал, и уже дважды объяснил, что не так в этих ветках. Более того, ты сам говоришь "привычные мне ветки зовутся bookmarks". Разберись сначала, как самому себе не противоречить.
_>>> Если же говорить о реально устоявшихся, то это будет скорее SVN и более старые системы — как думаешь, к какой из DVCS их терминология будет ближе? ) N>>К Git, если брать CVS. Вообще ни к чему из них, если брать SVN и учитывать варианты "скопировали в /release/foo весь /trunk, но в /release/foo/zuka скопировали /releng/bar/zuka". Но если не учитывать их — то SVN ближе к CVS и Git, чем к Hg, потому что нет действия типа "сегодня веткой X будет называться каталог Y". Вот если бы они ввели симлинки и назвали их ветками — было бы хоть как-то похоже.
_>А вот тут http://rsdn.ru/forum/flame.comp/6335381.1
Здравствуйте, alex_public, Вы писали:
_>>>Покажи к чему приведут аналогичные действия в git'e и мы вместе посмеёмся. ))) N>>Такой ситуации просто не возникнет. А если ты решишь вписать неадекватное имя ветки вручную в коммит — что ж, это было твоё решение. _>Т.е. я правильно понимаю, что при работе с Git рекомендуется не нарушать некие правила, а при работе с Mercurial наоборот? )))
Разница в том, что в Git при ветках, которые ветки, правила просты и логичны. В Hg разрыв между нормальным пониманием ветки и тем, что там называется этим словом, приводит к бардаку. Если переименуете на другой термин, который не конфликтует с языком, часть жалоб уйдёт.
_>>>О, кстати, ещё один практический нюанс вспомнился... Работа с автоматическими анонимными ветками намного удобнее в Mercurial. Собственно не помню как вообще в Git с ними работать (скажем аналог команды heads?). N>>Опиши желаемое подробнее, не понимаю. _>Ну очевидно же) Фиксируем некие изменения, потом откатываемся назад на одну ревизию,
Как именно откатываемся? Вообще удаляем последнюю ревизию или сохраняем?
_> снова что-то меняем и снова фиксируем (не создавая новых веток вообще).
Ну. Будет новый последний коммит в текущей ветке.
_> Кстати, аналогичного можно добиться и проще (как раз более практичный вариант) — фиксация своих изменений несколькими разработчиками в одну и ту же ветку, с последующей синхронизацией.
Пофиг, как ветка называется у каждого конкретного разработчика, важно, в какую в общем репо они вливают (и с какой мержатся).
_>Что будет в таком случае в git и как с этим удобно работать? )
Я продолжаю не понимать вопроса. Первый встречный вопрос: то изменение, которое было последним вначале, оно должно быть сохранено или нет?
_>В Mercurial всё будет крайне удобно и это собственно один из нормальных сценариев работы.
В Git всё будет "крайне удобно", но после того, как ты наконец объяснишь, чего ты именно хочешь и зачем.
N>>>>А часть одного файла? _>>>Эээ, что что? ) N>>Я занимаюсь лечением бага. Для его диагностики вставлено 6 мест отладочной печати. Затем вписано 4 исправления собственно этого бага, причём 2 из них на рефакторинг "выделить код в отдельный метод" и 2 на исправление ошибки. Всё это в одном файле. N>>Мне нужно создать 2 коммита — рефакторинг и исправление — и оставить отладочную печать на несколько дней, пока не завершится, грубо говоря, весь деплоймент. N>>Git даёт сразу несколько методов набирать только те патчи из всех изменений, которые нужны для текущего коммита. N>>Ни в одной другой VCS я такого не видел. Врапперы во всяких IDE не учитывать.
_>Ужасы какие) Как раз для таких дел и создают отдельные ветки (отладочная, релизная и т.п.).
При чём тут вообще какие-то отдельные ветки? Описанные проблемы и методы решения не зависят от того, это develop, old stable или что-то ещё.
Здравствуйте, Mazenrab, Вы писали:
AK>>я почему интересуюсь, для меня, как C# программера — это базовая операция — переименование класса (class per file). M>На днях натыкался — есть такая проблема.
Да нет такой проблемы, открой для себя "git log -M" или ещё круче — "git blame -C", который может найти, например, перемещённый метод из одного файла в другой (такого в hg вроде нет).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
противоположное мнение высказывается. ) ·>Ну, если более старые DVCS рассматривать, то да. Но накой DVCS hg начала что-то тянуть из centralised VCS типа svn... это не совсем разумное решение. Может в короткой перспективе, перетянуть юзеров, это и хорошо, но лучше в этом болоте не засиживаться.
Не, я не про старые DVCS. Там ниже было высказывание, что к CVS и SVN ближе Git, а не Mercurial. )
_>>Ну возьми просто один большой (скажем на мегабайт, для простоты эксперимента) и кинь его пустой репозиторий. Ну поменяй пару строк и зафиксируй. И посмотри размер хранилища. Для hg и для git. ·>Игрушечных экспериментов, которые плохо сработают для hg я могу тоже насочинять. Например, добавить тот же файл дважды в разные каталоги.
ОК, давай возьмём просто любой большой проект и кинем его в чистый репозиторий) Причём это ещё будет максимально лояльным для Git тестом, т.к. у него размер существенно растёт именно с числом изменений.
_>>Ну а что касается обмена изменениями, то для последних ревизий (где пара строк менялась) разница действительно не принципиальна (типа 100 байт или 200), а вот если взять все ревизии (тогда оно будет включать файлы целиком), то опять же будет весьма интересный результат... ·>Эээ.. А как ещё? Если хочется патчи, бери патчи.
Не, я не про это. Я про размер получаемого файла (в котором по сути содержится весь репозиторий). Какой он будет у Mercurial, а какой у Git. Тут же утверждали, что низкоуровневая архитектура у Git более продумана и позволяет большее сжатие и т.п. А на практике...
_>>·>...то в реальности делать repack после каждого изменения — глупость. _>>Согласен. ) И в таком случае выигрывать по размеру хранилища будет скорее Mercurial. ·>Будет, но не долго, до первого же repack.
Угу и потом ещё пару изменений продержится на минимуме, а потом снова... )))
Здравствуйте, netch80, Вы писали:
_>>Вообще то если уж брать реальную историю, то первой такой системой был не BitKeeper (кстати 1998 год, а не 2000), а некий Code Co-op. Однако это всё не имеет никакого значения, т.к. все эти системы были мало известны и соответственно не могли задавать никаких традиции в индустрии. N>Во-первых: я тоже далеко не первых назвал, я назвал хорошо известных предыдущих. N>Во-вторых, я не знаю, где ты был в этой индустрии в те времена, если ты не заметил, например, шума про то, что Линус, после того, как много лет "по матушке" посылал хотя бы за идею вести разработку или даже публичное репо нумерованных версий в доступных тогда средствах вроде CVS — вдруг разразился "все на BitKeeper!" — шок был весьма существенный. N>Я был тогда (как и сейчас) среди активных юниксоедов, подо мной была существенная часть ответственности интернет-провайдера, у нас были линуксы, и за всем этим я пристально следил (находясь на позиции "лучше CVS, чем ничего" — с чем регулярно спорил с активными линуксоманами).
Хы, в 1997 самый громкий шум в мире линуха был неслышным шорохом на уровне остальной IT индустрии. ))) Кстати, это и сейчас не так чтобы радикально изменилось, но хотя бы в мире сервером и встроенных систем люди прислушаются. ) А тогда это вообще были какие-то игры маргиналов. )
_>>Вообще то понятие ветка в Mercurial точно такое же, как и везде. Если ты не сумел разобраться, то это не значит что там что-то не так. Для начала не плохо бы почитать документацию. N>Я почитал, и попробовал, и уже дважды объяснил, что не так в этих ветках. Более того, ты сам говоришь "привычные мне ветки зовутся bookmarks". Разберись сначала, как самому себе не противоречить.
Не, ветки из git'a, которые не сохраняются, а просто являются указателями на последние ревизии — они похожи на bookmarks. А как раз в самом Mercurial нормальные ветки. Просто ты не понял что сам сделал в системе и решил из этого какие-то выводы извлечь. )))
_>>А вот тут http://rsdn.ru/forum/flame.comp/6335381.1
высказывается (и не мною) прямо противоположное мнение. ))) N>Я не вижу там никакого противоречия тому, что я говорю. Разъясни подробнее, если видишь.
Вроде как там ясно написано, что старым системам (cvs, svn и т.п.) ближе mercurial, а git наоборот отбросил все традиции и поэтому непривычен. Это полностью противоречит твой фразе о том, что к старым системам ближе git, а mercurial забил на традиции.
Здравствуйте, netch80, Вы писали:
N>Разница в том, что в Git при ветках, которые ветки, правила просты и логичны. В Hg разрыв между нормальным пониманием ветки и тем, что там называется этим словом, приводит к бардаку. Если переименуете на другой термин, который не конфликтует с языком, часть жалоб уйдёт.
Ещё раз поясняю: в mercurial как раз самые нормальные ветки, просто ты не разобрался. Например ты почему-то считаешь ветками только именованные, созданные с помощью специальной команды (как в git), в то время как в Mercurial любое разветвление (создаваемое автоматически при наличие двух разных изменений относительно одного родительского) является ветками. Причём с ними можно полноценно работать со всеми удобствами.
N>>>Опиши желаемое подробнее, не понимаю. _>>Ну очевидно же) Фиксируем некие изменения, потом откатываемся назад на одну ревизию, N>Как именно откатываемся? Вообще удаляем последнюю ревизию или сохраняем?
Естественно сохраняем и собираемся потом использоваться (возможно ещё пару изменений там добавим, а потом сделаем слияние).
_>> Кстати, аналогичного можно добиться и проще (как раз более практичный вариант) — фиксация своих изменений несколькими разработчиками в одну и ту же ветку, с последующей синхронизацией. N>Пофиг, как ветка называется у каждого конкретного разработчика, важно, в какую в общем репо они вливают (и с какой мержатся).
Зачем нам лишняя сущность типа третьего репозитория? ) Для работы двух разработчиков вполне достаточно их двух локальных. Но если ты так хочешь, то можно и с 3-им. И да, используем одну ветку (с одним названием).
Кстати, в режиме по умолчанию Mercurial синхронизирует сразу все ветки в репозиторию. Это так, к сведению. )
_>>Что будет в таком случае в git и как с этим удобно работать? ) N>Я продолжаю не понимать вопроса. Первый встречный вопрос: то изменение, которое было последним вначале, оно должно быть сохранено или нет?
Ответил выше. )
_>>В Mercurial всё будет крайне удобно и это собственно один из нормальных сценариев работы. N>В Git всё будет "крайне удобно", но после того, как ты наконец объяснишь, чего ты именно хочешь и зачем.
Ну сейчас увидим как удобно будет. )
_>>Ужасы какие) Как раз для таких дел и создают отдельные ветки (отладочная, релизная и т.п.). N>При чём тут вообще какие-то отдельные ветки? Описанные проблемы и методы решения не зависят от того, это develop, old stable или что-то ещё.
Ну если тебе требуется наличие в репозитории двух версий одного кода, одну с отладочной печатью, а другую без, то это как раз удобнее делать через ветки. )
противоположное мнение высказывается. ) _>·>Ну, если более старые DVCS рассматривать, то да. Но накой DVCS hg начала что-то тянуть из centralised VCS типа svn... это не совсем разумное решение. Может в короткой перспективе, перетянуть юзеров, это и хорошо, но лучше в этом болоте не засиживаться. _>Не, я не про старые DVCS. Там ниже было высказывание, что к CVS и SVN ближе Git, а не Mercurial. )
Там вроде про ветки. Ветки — да, в hg это нечто уникальное, неповторимое понимание, попытка натянуть сову на глобус. Где ещё есть многоголовые ветки?
_>>>Ну возьми просто один большой (скажем на мегабайт, для простоты эксперимента) и кинь его пустой репозиторий. Ну поменяй пару строк и зафиксируй. И посмотри размер хранилища. Для hg и для git. _>·>Игрушечных экспериментов, которые плохо сработают для hg я могу тоже насочинять. Например, добавить тот же файл дважды в разные каталоги. _>ОК, давай возьмём просто любой большой проект и кинем его в чистый репозиторий) Причём это ещё будет максимально лояльным для Git тестом, т.к. у него размер существенно растёт именно с числом изменений.
Дело было вечером, делать было нечего. Я взял openssl-1.0.1r.tar.gz, 4.4мб, распаковал 44мб исходников, 2183 файлов, 130 каталогов... Что-то плохо всё с hg:
-
git
hg
hg/git
init
0.223
0.714
add
2.801
1.143
commit
0.870
5.327
add+commit
3.671
6.470
1.8
size
32
30
0.9
gc
5.670
-
size final
5.8
30
5.2
Время в секундах, размер в мегабайтах. hg 3.4, git 2.0.3, ubuntu, linux 4.2.0-23.
Очень интересно — размер repacked git репо сравним с tar.gz тех же данных.
Проведи такой же эксперимент — интересно будут такие же результаты или я что-то не так померил...
_>>>Ну а что касается обмена изменениями, то для последних ревизий (где пара строк менялась) разница действительно не принципиальна (типа 100 байт или 200), а вот если взять все ревизии (тогда оно будет включать файлы целиком), то опять же будет весьма интересный результат... _>·>Эээ.. А как ещё? Если хочется патчи, бери патчи. _>Не, я не про это. Я про размер получаемого файла (в котором по сути содержится весь репозиторий). Какой он будет у Mercurial, а какой у Git. Тут же утверждали, что низкоуровневая архитектура у Git более продумана и позволяет большее сжатие и т.п. А на практике...
... так и получается.
А вообще, какого файла?.. Если у тебя полная ревизия, то да, будет полный снапшот, если это diff, будет diff. Как это зависит от vcs?
_>>>Согласен. ) И в таком случае выигрывать по размеру хранилища будет скорее Mercurial. _>·>Будет, но не долго, до первого же repack. _>Угу и потом ещё пару изменений продержится на минимуме, а потом снова... )))
Может в каких-то ситуациях так и может быть, но обычно с точностью до наоборот.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
), в которых git сильно выигрывает в размере репозитория у своих конкурентов. Правда там мелким шрифтом приписано, что это тестируется после применения repack в git. ))) Ну т.е. если мы после каждого изменения будем делать repack, то тогда git действительно всех обойдёт (правда советую в начале глянуть сколько времени оно занимает). А вот если взглянуть на реальность, то... )))
