Здравствуйте, alex_public, Вы писали:
_>·>Фундамент git — лучше. Вместо традиционного (тянущееся начиная с rcs?) append-only лога, да ещё и per-file используется принципиально другой подход, ассоциативное object-хранилище. _>Это смотря на каком уровне смотреть. Формально да, одно хранит дифы, а другое вроде как сами файлы. Но фокус в том, что если бы оно реально хранило сами файлы, то размер хранилища был бы нереальным. Так что в итоге и второе хранит дифы, просто они там для сжатия, а не для идеологии.
Причём эти дельты в Git необязательно линейные, необязательно между одними и теми же файлами, и необязательно вперёд по времени — будет выбран оптимальный вариант по эвристикам и нескольким попыткам.
Здравствуйте, netch80, Вы писали:
_>>- проблема с сохранением истории в git. В mercurial всегда можно найти источник проблемы, а в git'е далеко не всегда. N>Совершенно непонятно. Что есть "проблема" в данном случае? Источник конкретного изменения? Ищется по истории без проблем, на каждую версию строчки или бинаря есть id коммита, из которого она возникла. Развилки? Они существуют во всех DVCS.
Даже если забыть о "низкоуровневых" возможностях правки истории в git, то остаётся ещё главное — разное понимание термина ветка. Вот https://habrahabr.ru/post/123700/ известный пример на эту тему.
_>>- возможность получить гигабайтный патч при слияние веток в git. N>Любое слияние отражает дифф с исходными версиями. "Гигабайтный патч" означает сведение существенно несовместимых вариантов. Проблема общая для всех DVCS, но в случае Git имеем один из лучших, испытанный на практике, мержер.
Нет, всё зависит от способа работы с данными. Тут как раз это и обсуждали выше, называя реализацию git'a более технически совершенной. Однако у всего есть обратная сторона...
_>>- проблема с кодировками в путях. Надеюсь хоть это уже исправили? ) N>Этой проблемы никогда не было у Git. Имя объекта это NUL-terminated строка байт, даже понимание этого имени как пути уже является свойством внешнего слоя, а не ядра. N>Если она есть у Windows, то это проблема кодировок Windows и конкретных реализаций Git клиента. Бардак с кодировками (ANSI/OEM/Unicode) в Windows такой, что я всегда забывал, что в них где, через 5 минут после того, как разобрался.
Проблема не у windows (проблемы будут и в линухе), а именно у git'a при работе с ним из разных ОС. Да, возможно это правильно называть проблемой "конкретных реализаций git клиента"... Но собственно это же и есть сам git (у него нет никакой обязательной серверной части).
Самое забавное, что различные GUI-оболочки/IDE устраняют эту проблему, передавая в git данные в каком-то одном формате. Что мешало сделать это банальное исправление в самом git — непонятно.
_>>- слабая работа с хуками и другими расширениями в git N>Мне не с чем сравнивать, но вопрос в том, насколько реально нужна "сильная" в твоём понимании, и насколько она логична.
Не понял про что ты спрашиваешь) Про нужность хуков и расширений вообще в dcvs или же про удобство их реализации в Mercurial? Если про второе, то достаточно сказать про возможность реализации на уровне внутреннего вызова кода на Питоне.
_>>- заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs. N>Система команд очень удобна из логики "если действие с базовой концепцией X, команда будет называться X".
Ну я уже сказал, что это дело вкуса, а не технический вопрос. ) Но мнение что система команд mercurial удобнее своего аналога из git'a я видел неоднократно. )
Здравствуйте, D.Lans, Вы писали:
DL>Вот поэтому я и пользуюсь Mercurial. Есть свои проблемы, в частности уже пару раз ломал репозиторий, что приходилось пересоздавать с нуля (хотя может можно было и починить, нз), но в целом ощущения от использования этой VCS очень приятные. Всё чисто, понятно и логично.
А, то есть поломка репозитория в 0 это логично.
DL>Пользоваться меркуриалов по сравнению с гитом всё равно что программировать на питоне вместо си.
Попробуем-с.
$ hg init
$ echo 1 > a
$ hg add a
$ hg ci -m a=1
$ echo 2 > b
$ hg add b
$ hg ci -m b=2
$ hg log
$ echo 3 > a
$ hd add a
a already tracked!
Это что, я теперь должен говорить hg ci с явным списком файлов?
А если их десятка два, которые надо отобрать среди 60 изменённых, я должен имена всех файлов писать?
А если мне не все изменения из конкретного файла надо отобрать, только часть?
Кстати, я раскомментировал pager в extensions, а hg help log и аналогичные команды продолжают плеваться на экран полным текстом за раз. Почему?
DL>Хайпа вокруг гита не понимаю. DL>я в недоумении развожу руками.
Есть такие понятия — удобство, логичность, соответствие ожидаемому. Наконец, банально современные возможности, а не уровень CVS, как в случае с этим add.
Здравствуйте, alex_public, Вы писали:
_>Даже если забыть о "низкоуровневых" возможностях правки истории в git, то остаётся ещё главное — разное понимание термина ветка. Вот https://habrahabr.ru/post/123700/ известный пример на эту тему.
В этом примере не разное понимание, а одна мелочь — фиксация имени ветки в коммите hg. Да, я действительно не понимаю, зачем это настолько нужно, чтобы выдвигать на киллер-фичу, при том, что реально ни одна другая SCM это не ведёт.
Добавить принудительно имя ветки в сообщение тривиально за счёт локального хука, но накойхер? Там лучше держать, например, герритовский change-id.
Остальные обобщения автора статьи про "подделку истории", "исторический ревизионизм" оставим на совести постмарксистского ярлыковедения.
_>>>- возможность получить гигабайтный патч при слияние веток в git. N>>Любое слияние отражает дифф с исходными версиями. "Гигабайтный патч" означает сведение существенно несовместимых вариантов. Проблема общая для всех DVCS, но в случае Git имеем один из лучших, испытанный на практике, мержер. _>Нет, всё зависит от способа работы с данными. Тут как раз это и обсуждали выше, называя реализацию git'a более технически совершенной. Однако у всего есть обратная сторона...
Можно конкретнее? Не понимаю.
_>>>- проблема с кодировками в путях. Надеюсь хоть это уже исправили? ) N>>Этой проблемы никогда не было у Git. Имя объекта это NUL-terminated строка байт, даже понимание этого имени как пути уже является свойством внешнего слоя, а не ядра. N>>Если она есть у Windows, то это проблема кодировок Windows и конкретных реализаций Git клиента. Бардак с кодировками (ANSI/OEM/Unicode) в Windows такой, что я всегда забывал, что в них где, через 5 минут после того, как разобрался. _>Проблема не у windows (проблемы будут и в линухе), а именно у git'a при работе с ним из разных ОС. Да, возможно это правильно называть проблемой "конкретных реализаций git клиента"... Но собственно это же и есть сам git (у него нет никакой обязательной серверной части).
Если кодировка путей стандартизована на уровне политики репо (считаю utf-8 умолчанием для 99.9% случаев), проблемы нет. Если нужно разбираться с разными локальными кодировками, то что это вообще за системы такие, и почему клиент с этим не разбирается, несмотря на явные недвусмысленные рекомендации?
_>Самое забавное, что различные GUI-оболочки/IDE устраняют эту проблему, передавая в git данные в каком-то одном формате. Что мешало сделать это банальное исправление в самом git — непонятно.
Именно то, что это вопрос к оболочкам (и файловое дерево — стандартная оболочка).
_>>>- слабая работа с хуками и другими расширениями в git N>>Мне не с чем сравнивать, но вопрос в том, насколько реально нужна "сильная" в твоём понимании, и насколько она логична. _>Не понял про что ты спрашиваешь) Про нужность хуков и расширений вообще в dcvs или же про удобство их реализации в Mercurial? Если про второе, то достаточно сказать про возможность реализации на уровне внутреннего вызова кода на Питоне.
Про их состав. Есть где-то пример позарез нужного хука, который не сделали в Git?
_>>>- заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs. N>>Система команд очень удобна из логики "если действие с базовой концепцией X, команда будет называться X". _>Ну я уже сказал, что это дело вкуса, а не технический вопрос. ) Но мнение что система команд mercurial удобнее своего аналога из git'a я видел неоднократно. )
Если есть что сравнить в плане разделения идентичных фич по командам, покажи пример. Что я пока увидел — просто отсутствие возможностей, к которым я привык как к 100% доступной и необходимой базе, типа накопить изменения чанками из разных файлов перед коммитом.
Здравствуйте, alex_public, Вы писали:
_>- проблема с сохранением истории в git. В mercurial всегда можно найти источник проблемы, а в git'е далеко не всегда.
Эээ... А конкретно? История иммутабельная, какие могут быть проблемы? Может кто-то просто не слышал о reflog?
_>- возможность получить гигабайтный патч при слияние веток в git.
Каким образом? И зачем вообще получать патчи при слиянии?
_>- проблема с кодировками в путях. Надеюсь хоть это уже исправили? )
Не знаю, думаю да, это был результат unix-only.
_>- слабая работа с хуками и другими расширениями в git
Что это значит?
_>- заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs.
Верно, дело вкуса. Результат отказа от традиционной идеологии.
_>·>Фундамент git — лучше. Вместо традиционного (тянущееся начиная с rcs?) append-only лога, да ещё и per-file используется принципиально другой подход, ассоциативное object-хранилище. _>Это смотря на каком уровне смотреть. Формально да, одно хранит дифы, а другое вроде как сами файлы. Но фокус в том, что если бы оно реально хранило сами файлы, то размер хранилища был бы нереальным. Так что в итоге и второе хранит дифы, просто они там для сжатия, а не для идеологии.
Правильно, SRP применён — хранение абстрагировано от представления, что облегчает многие фичи. И, кстати, даёт больше возможностей для оптимизации сжатия.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Пусть у меня есть текущая разработка из, например, 20 коммитов. Я хочу от 15-го из них отцепить, скажем, "стабильную" ветку, потому что последними 5 я начал ломать что-то. То есть ветка должна стартовать с 15-го коммита.
Что надо было сказать гуглу, чтобы он объяснил, как это делается?
(Для сравнения: Git: тривиально ищется по checkout, дальше написано про ключик -b и commit id. Но если вы решите поискать в branch, там тоже есть эта возможность!)
Путём поисков вбок нашёл главу "Create a Branch From an Older Revision". OK, пробую. Требуется вызвать hg update + hg branch, причём про hg branch с именем сказано "set the current branch name", что любой нормальный человек понимает как переход на уже созданную ветку или смену формального названия, но не создание новой!
Текущая правка у меня номер 3. Пишу "hg update -r 2", пишет "1 files updated".
Как мне узнать теперь, где я стою? "hg status" вообще ничего не пишет. (Git'овый пишет в этом случае, какой опорный коммит, состояние совпадает с какой-то веткой или это detached.)
hg branch? Не то. hg heads? Не то.
Инструкции молчат. Как я могу быть уверен, что делаю копию именно с нужного состояния? Только по тому, что hg update промолчала? А если я схожу на перекур?
Если авторы не в состоянии отработать с точки зрения даже простейший сценарий использования, как можно предлагать использовать их творение?
Здравствуйте, netch80, Вы писали:
N>В этом примере не разное понимание, а одна мелочь — фиксация имени ветки в коммите hg. Да, я действительно не понимаю, зачем это настолько нужно, чтобы выдвигать на киллер-фичу, при том, что реально ни одна другая SCM это не ведёт. N>Добавить принудительно имя ветки в сообщение тривиально за счёт локального хука, но накойхер? Там лучше держать, например, герритовский change-id. N>Остальные обобщения автора статьи про "подделку истории", "исторический ревизионизм" оставим на совести постмарксистского ярлыковедения.
Разная идеология понятия "ветка". И на мой взгляд для нормальной контролируемой команды (а не стихийного опенсорса) подход Mercurial правильнее. Да, кстати, вариант веток в стиле git'a там тоже имеется (называется bookmarks), но вроде не пользуется особой популярностью. )))
_>>Проблема не у windows (проблемы будут и в линухе), а именно у git'a при работе с ним из разных ОС. Да, возможно это правильно называть проблемой "конкретных реализаций git клиента"... Но собственно это же и есть сам git (у него нет никакой обязательной серверной части). N>Если кодировка путей стандартизована на уровне политики репо (считаю utf-8 умолчанием для 99.9% случаев), проблемы нет. Если нужно разбираться с разными локальными кодировками, то что это вообще за системы такие, и почему клиент с этим не разбирается, несмотря на явные недвусмысленные рекомендации?
Ну ОК, договорились мы всё хранить в utf-8. Можно теперь узнать с помощью какой настройки я могу сообщить об этом git'у под виндой (т.к. там дефолтная другая будет)? Естественно мы про работу из консоли говорим. )
N>>>Мне не с чем сравнивать, но вопрос в том, насколько реально нужна "сильная" в твоём понимании, и насколько она логична. _>>Не понял про что ты спрашиваешь) Про нужность хуков и расширений вообще в dcvs или же про удобство их реализации в Mercurial? Если про второе, то достаточно сказать про возможность реализации на уровне внутреннего вызова кода на Питоне. N>Про их состав. Есть где-то пример позарез нужного хука, который не сделали в Git?
Ну вообще то я говорил не про набор хуков, а про удобство расширения. Но даже если говорить про набор, то помнится в git'е раньше не было многих. Например preoutgoing и т.п. Сейчас не знаю, не смотрел, может и добавили.
N>>>Система команд очень удобна из логики "если действие с базовой концепцией X, команда будет называться X". _>>Ну я уже сказал, что это дело вкуса, а не технический вопрос. ) Но мнение что система команд mercurial удобнее своего аналога из git'a я видел неоднократно. ) N>Если есть что сравнить в плане разделения идентичных фич по командам, покажи пример. Что я пока увидел — просто отсутствие возможностей, к которым я привык как к 100% доступной и необходимой базе, типа накопить изменения чанками из разных файлов перед коммитом.
По умолчанию фиксируются все модифицированные файлы и это намного удобнее (т.к. это самый частый вариант использования), чем каждый раз писать "-a". Если надо зафиксировать изменение не всех файлов, то точно так же как и в git передаётся список в команду commit. Лично я же в таком случае предпочитаю снимать галочки в TortoiseHg. )))
Да, что касается формального сравнения разных команд... Я никогда об этом специально не задумывался, просто интуитивно чувствуется удобство в определённых случаях (потому и говорю что дело вкуса). Но вот сейчас решил чуть задуматься. Как там в git'e скажем насчёт аналога команды hg incoming?
Здравствуйте, ·, Вы писали:
_>>- проблема с сохранением истории в git. В mercurial всегда можно найти источник проблемы, а в git'е далеко не всегда. ·>Эээ... А конкретно? История иммутабельная, какие могут быть проблемы? Может кто-то просто не слышал о reflog? _>>- возможность получить гигабайтный патч при слияние веток в git. ·>Каким образом? И зачем вообще получать патчи при слиянии? _>>- проблема с кодировками в путях. Надеюсь хоть это уже исправили? ) ·>Не знаю, думаю да, это был результат unix-only. _>>- слабая работа с хуками и другими расширениями в git ·>Что это значит?
Отвечал уже в сообщениях выше на всё перечисленное.
_>>- заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs. ·>Верно, дело вкуса. Результат отказа от традиционной идеологии.
Эмм, а что значит традиционная идеология в данном случае?
_>>·>Фундамент git — лучше. Вместо традиционного (тянущееся начиная с rcs?) append-only лога, да ещё и per-file используется принципиально другой подход, ассоциативное object-хранилище. _>>Это смотря на каком уровне смотреть. Формально да, одно хранит дифы, а другое вроде как сами файлы. Но фокус в том, что если бы оно реально хранило сами файлы, то размер хранилища был бы нереальным. Так что в итоге и второе хранит дифы, просто они там для сжатия, а не для идеологии. ·>Правильно, SRP применён — хранение абстрагировано от представления, что облегчает многие фичи. И, кстати, даёт больше возможностей для оптимизации сжатия.
Однако на практике получается наоборот. Попробуй сравнить размеры хранилищ и размеры пакетов (которые bundle — самый удобный способ сравнить необходимый объём данных для синхронизации по сети) git и mercurial для одинаковых репозиториев. ) Кстати, помнится видел разные вроде как тесты (почему-то публикуемые на kernel.org — какое совпадение ), в которых git сильно выигрывает в размере репозитория у своих конкурентов. Правда там мелким шрифтом приписано, что это тестируется после применения repack в git. ))) Ну т.е. если мы после каждого изменения будем делать repack, то тогда git действительно всех обойдёт (правда советую в начале глянуть сколько времени оно занимает). А вот если взглянуть на реальность, то... )))
Здравствуйте, netch80, Вы писали:
N>Как мне узнать теперь, где я стою? "hg status" вообще ничего не пишет. (Git'овый пишет в этом случае, какой опорный коммит, состояние совпадает с какой-то веткой или это detached.) N>hg branch? Не то. hg heads? Не то. N>Инструкции молчат. Как я могу быть уверен, что делаю копию именно с нужного состояния? Только по тому, что hg update промолчала? А если я схожу на перекур? N>Если авторы не в состоянии отработать с точки зрения даже простейший сценарий использования, как можно предлагать использовать их творение?
Достаточно почитать документацию (или ты git тоже изучал методом тыка?): status — это про файлы, а про хранилище это summary. Хотя на самом деле такие очевидные вещи можно было и без документации увидеть, достаточно было ввести просто команду hg и почитать на экране список базовых команд. )))
насколько помню, раньше была проблема у гита с одновременным переименованием и изменением файла. это уже починили или все так же? вроде как история "терялась"
я почему интересуюсь, для меня, как C# программера — это базовая операция — переименование класса (class per file).
Здравствуйте, alex_public, Вы писали:
N>>Как мне узнать теперь, где я стою? "hg status" вообще ничего не пишет. (Git'овый пишет в этом случае, какой опорный коммит, состояние совпадает с какой-то веткой или это detached.) N>>hg branch? Не то. hg heads? Не то. N>>Инструкции молчат. Как я могу быть уверен, что делаю копию именно с нужного состояния? Только по тому, что hg update промолчала? А если я схожу на перекур? N>>Если авторы не в состоянии отработать с точки зрения даже простейший сценарий использования, как можно предлагать использовать их творение? _>Достаточно почитать документацию (или ты git тоже изучал методом тыка?): status — это про файлы, а про хранилище это summary.
WTF? Я как раз спрашиваю про то, к чему относится рабочая копия, значит, это про файлы, а не про хранилище.
_> Хотя на самом деле такие очевидные вещи можно было и без документации увидеть, достаточно было ввести просто команду hg и почитать на экране список базовых команд. )))
И перебирать их всех? Когда их больше 5, этот совет заведомо деструктивен.
Здравствуйте, alex_public, Вы писали:
N>>В этом примере не разное понимание, а одна мелочь — фиксация имени ветки в коммите hg. Да, я действительно не понимаю, зачем это настолько нужно, чтобы выдвигать на киллер-фичу, при том, что реально ни одна другая SCM это не ведёт. N>>Добавить принудительно имя ветки в сообщение тривиально за счёт локального хука, но накойхер? Там лучше держать, например, герритовский change-id. N>>Остальные обобщения автора статьи про "подделку истории", "исторический ревизионизм" оставим на совести постмарксистского ярлыковедения.
_>Разная идеология понятия "ветка".
Вот я _обожаю_ такие высказывания. Как только возникают вопросы про конкретные особенности веток — начинаются рассказы про "идеологию". "У нас тут своя атмосфера", видите ли. При этом ничего конкретного по сути вопроса не говорится, ссылка на идеологию всё спишет.
_> И на мой взгляд для нормальной контролируемой команды (а не стихийного опенсорса) подход Mercurial правильнее. Да, кстати, вариант веток в стиле git'a там тоже имеется (называется bookmarks), но вроде не пользуется особой популярностью. )))
Отлично. Вот у меня сейчас получилась вот такая вот картинка:
Хорошо видно, что "branch: x1" написано на двух коммитах из разных веток (цепочек из коммитов, a.k.a. changeset'ов)? Простите, это из какой такой идеологии "бранчем" именуется нечто, что может перескочить между реальными ветками разработки? Теперь ветки — это не те ветки, а не те ветки — это ветки?
Можно сколько угодно фантазировать на тему "своей атмосферы", но если появляется какая-то сущность, которая называется "ветка", а при этом становится каким-то переходящим красным знаменем между коммитами разных веток —
Ирка оббивала сигарету и шустренько цапала следующую страницу, и лицо у нее вытягивалось. „Он думал, — упавшим голосом читала она, — что трава, колышущаяся по ветру за пригорком, одна трава — это трава целиком, а трава целиком — это одна трава. Если не так, думал он, то ему, имеющему только имя, нет причины умирать…“ — „Е!..“ — икал Малянов. „Ну я не понимаю! — рыдающе восклицала Ирка. — Я вообще не понимаю, что хотел сказать автор! — Она вчитывалась еще раз. — …Одна трава — это трава целиком… а целиком — это одна трава… Слушай, может, это связано с восточными философиями? Дзэн, синто… что там у них еще… дао… Может, Глухову позвонить? Как ты думаешь?“ — „Я думаю одно, — отвечал Малянов, от обилия травы тоже несколько стервенея. — В пятницу мы должны сдать чистовой текст. Полностью. Иначе следующего заказа может вообще не быть.
это должно было называться тегом, флагом, шестиногим крокодилом или ящиком красной икры, но это не ветка. dixi, блин.
_>Ну ОК, договорились мы всё хранить в utf-8. Можно теперь узнать с помощью какой настройки я могу сообщить об этом git'у под виндой (т.к. там дефолтная другая будет)? Естественно мы про работу из консоли говорим. )
Вот честно: я винду не знаю, не умею, что там творится в её консоли — не знаю, и лечится ли это там вообще, и как именно — тоже я non rubrum legionem. Пусть мёртвые хоронят своих мертвецов, то есть те, кто мучают винду, разбираются с тем, как мучить винду. Меня эти 100500 оттенков серого не волнуют.
_>Ну вообще то я говорил не про набор хуков, а про удобство расширения. Но даже если говорить про набор, то помнится в git'е раньше не было многих. Например preoutgoing и т.п. Сейчас не знаю, не смотрел, может и добавили.
Почитал про preoutgoing. Смысла не понял. Заодно прочёл, что в нём ничего не известно и что он не зовётся при push, хотя зовётся при передаче в другое репо. Какая-то совсем вещь в себе, или опять та трава, которая не та трава.
_>По умолчанию фиксируются все модифицированные файлы и это намного удобнее (т.к. это самый частый вариант использования), чем каждый раз писать "-a". Если надо зафиксировать изменение не всех файлов, то точно так же как и в git передаётся список в команду commit. Лично я же в таком случае предпочитаю снимать галочки в TortoiseHg. )))
А часть одного файла?
Под Git я лучше алиас напишу типа "aa = add -A", если мне такое потребуется. Пока что не требовалось, я категорически считаю, что если это не какой-нибудь скрипт типа etckeeper, то добавлять все безусловно — диверсия, а если такой скрипт, то он сам сможет вызвать даже с длинной опцией. Считаю это умолчание "не сказано — значит все" грубейшей диверсией.
_>Да, что касается формального сравнения разных команд... Я никогда об этом специально не задумывался, просто интуитивно чувствуется удобство в определённых случаях (потому и говорю что дело вкуса). Но вот сейчас решил чуть задуматься. Как там в git'e скажем насчёт аналога команды hg incoming?
Делается через fetch+diff. А какой смысл в команде в таком виде, как в hg? На каждый вызов выкачивать список изменений, показывать их, но не сохранять локально? А если два вызова, оно в состоянии это закэшировать? Юзкейс совершенно непонятен.
И пока что я вижу в hg в основном такие хохмы. "Ветки", которые не ветки. "Закладки", которые тем не менее держат на себе состояние репо, хотя по смыслу названия они должны быть просто тегами. Команды с непонятным юзкейсом и заведомо неэффективным стилем исполнения. Зачем всё это?
Здравствуйте, netch80, Вы писали:
_>>Достаточно почитать документацию (или ты git тоже изучал методом тыка?): status — это про файлы, а про хранилище это summary. N>WTF? Я как раз спрашиваю про то, к чему относится рабочая копия, значит, это про файлы, а не про хранилище.
Текущая ревизия — это понятие глобальное на все файлы, т.е. относится к хранилищу.
_>> Хотя на самом деле такие очевидные вещи можно было и без документации увидеть, достаточно было ввести просто команду hg и почитать на экране список базовых команд. ))) N>И перебирать их всех? Когда их больше 5, этот совет заведомо деструктивен.
Их больше 5, но при этом около каждой из них чётко указано предназначение, так что ничего перебирать не требуется.
P.S. Что-то ты в этой темке прямо разошёлся (хотя ничего по делу я так и не увидел, правда и не рассчитывал: выбор между git и mercurial — это реально дело вкуса), а вот про эту http://rsdn.ru/forum/flame.comp/6332704
Здравствуйте, D.Lans, Вы писали:
DL>Хайпа вокруг гита не понимаю. Ладно самое красноглазное подмножество линуксоидов-ядерщиков в своём мирке юзают что им удобнее (белоглазые же линуксоиды, я слышал, почётно восседают на bazaar), но гит с хрустом начинают жевать маководы и виндузятники (к коим отношусь и я), с улыбкой гарольда-скрывающего-боль нахваливая и зазывая всех присоединиться к их клёвым проектам, худо-бедно выложенным на модный нынче гитхаб (но которые почему-то так и не получают должной популярности), я в недоумении развожу руками.
ЩИТО? Откуда вы такую траву взяли?
Я не понимаю сторонников hg. Они массово не понимают как вообще работают DVCS. Git вообще тупой как пробка, там сложного нет ничего. Банально достаточно запомнить, что коммиты образуют цепочку хэшей и всё.
Достаточно уметь это понимать, и всё в git становится понятным.
Здравствуйте, AK107, Вы писали:
AK>можно с вопросом влезть? AK>насколько помню, раньше была проблема у гита с одновременным переименованием и изменением файла. это уже починили или все так же? вроде как история "терялась"
Не терялась. Но и не сохранялась. История подобного рода может только создаваться в процессе чтения истории изменений. На уровне коммита есть только новое состояние двух объектов — исходных файлов. Само понимание того, что произошёл перенос кода, возникает на основании сравнения объектов — источников и объектов — приёмников и определяется долей неизменённого кода при этом переносе (точной границы не помню, навскидку это около 70%).
Да, я тоже хотел бы, как в darcs, алгебру изменений с возможностью логически определять каждое из них в стиле "переименование", "перенос", "форматирование" и т.п. — это очень облегчает мержинг. Но реально это не выжило ни в одной из современных массово используемых DVCS.
AK>я почему интересуюсь, для меня, как C# программера — это базовая операция — переименование класса (class per file).
Сколько при этом меняется внутри того файла? Если, например, в среднем одна строчка из 10, в истории будет факт переименования с указанием типа "91% similarity".
Здравствуйте, alex_public, Вы писали:
_>>>Достаточно почитать документацию (или ты git тоже изучал методом тыка?): status — это про файлы, а про хранилище это summary. N>>WTF? Я как раз спрашиваю про то, к чему относится рабочая копия, значит, это про файлы, а не про хранилище. _>Текущая ревизия — это понятие глобальное на все файлы, т.е. относится к хранилищу.
Оно не относится к хранилищу. Оно относится к состоянию рабочей копии. Хранилище при этом не меняется, как бы я ни двигал, какой именно коммит текущий выбранный.
_>P.S. Что-то ты в этой темке прямо разошёлся (хотя ничего по делу я так и не увидел, правда и не рассчитывал: выбор между git и mercurial — это реально дело вкуса),
Когда (см. соседнее сообщение) меня какая-то тулза заставляет переопределить давно устоявшиеся, стандартные по отрасли понятия — это уже не обычное дело вкуса, это bdsm.
_> а вот про эту http://rsdn.ru/forum/flame.comp/6332704
совсем забыл — нечего там сказать, как я понимаю? )))
Прошу запомнить раз и навсегда: отсутствие ответа не означает _ничего_. Ни "нечего сказать", ни согласия, ни чего-то подобного в принципе. Оно может означать, что участник занят другим, что собирает информацию, что намеренно решил отложить, вообще что угодно. У нас тут не платная техподдержка, у нас свободное самовыражение в рамках правил. В следующий раз я на подобный наезд на грани хамства просто пошлю куда подальше в ответ и поставлю в игнор.
Во-вторых, раз уж я тут написал предыдущие 5 строк: когда я разберусь, что там и почему, и будет, что ответить по сути — отвечу, с вероятностью процентов 90. Когда именно — не знаю. Иногда я на RSDN месяцами не хожу. Иногда поднимаю темы годовой давности. Для меня в таких темах время между репликами не играет вообще никакой роли. Если это не устраивает — никому не навязываюсь.
Здравствуйте, netch80, Вы писали:
_>>Разная идеология понятия "ветка". N>Вот я _обожаю_ такие высказывания. Как только возникают вопросы про конкретные особенности веток — начинаются рассказы про "идеологию". "У нас тут своя атмосфера", видите ли. При этом ничего конкретного по сути вопроса не говорится, ссылка на идеологию всё спишет.
Разница очевидна. В git ветка — это что-то временное, а в mercurial ветки остаются навсегда в истории.
_>> И на мой взгляд для нормальной контролируемой команды (а не стихийного опенсорса) подход Mercurial правильнее. Да, кстати, вариант веток в стиле git'a там тоже имеется (называется bookmarks), но вроде не пользуется особой популярностью. ))) N>Отлично. Вот у меня сейчас получилась вот такая вот картинка: N>... N>Хорошо видно, что "branch: x1" написано на двух коммитах из разных веток (цепочек из коммитов, a.k.a. changeset'ов)? Простите, это из какой такой идеологии "бранчем" именуется нечто, что может перескочить между реальными ветками разработки? Теперь ветки — это не те ветки, а не те ветки — это ветки?
Покажи к чему приведут аналогичные действия в git'e и мы вместе посмеёмся. )))
О, кстати, ещё один практический нюанс вспомнился... Работа с автоматическими анонимными ветками намного удобнее в Mercurial. Собственно не помню как вообще в Git с ними работать (скажем аналог команды heads?).
_>>Ну вообще то я говорил не про набор хуков, а про удобство расширения. Но даже если говорить про набор, то помнится в git'е раньше не было многих. Например preoutgoing и т.п. Сейчас не знаю, не смотрел, может и добавили. N>Почитал про preoutgoing. Смысла не понял. Заодно прочёл, что в нём ничего не известно и что он не зовётся при push, хотя зовётся при передаче в другое репо. Какая-то совсем вещь в себе, или опять та трава, которая не та трава.
Полезно для создания нестандартных каналов передачи (скажем с шифрованием и т.п.).
_>>По умолчанию фиксируются все модифицированные файлы и это намного удобнее (т.к. это самый частый вариант использования), чем каждый раз писать "-a". Если надо зафиксировать изменение не всех файлов, то точно так же как и в git передаётся список в команду commit. Лично я же в таком случае предпочитаю снимать галочки в TortoiseHg. ))) N>А часть одного файла?
Эээ, что что? )
N>Под Git я лучше алиас напишу типа "aa = add -A", если мне такое потребуется. Пока что не требовалось, я категорически считаю, что если это не какой-нибудь скрипт типа etckeeper, то добавлять все безусловно — диверсия, а если такой скрипт, то он сам сможет вызвать даже с длинной опцией. Считаю это умолчание "не сказано — значит все" грубейшей диверсией.
Ну я же говорю, что дело вкуса. Кто-то любит удобство по умолчанию, а кто-то любит вписывать все детали сам. А при использование из нормального GUI (кстати как раз с этим у git были большие проблемы, но сейчас вроде как частично исправилось) вообще разницы нет какой dcvs пользуешься. )))
_>>Да, что касается формального сравнения разных команд... Я никогда об этом специально не задумывался, просто интуитивно чувствуется удобство в определённых случаях (потому и говорю что дело вкуса). Но вот сейчас решил чуть задуматься. Как там в git'e скажем насчёт аналога команды hg incoming? N>Делается через fetch+diff. А какой смысл в команде в таком виде, как в hg? На каждый вызов выкачивать список изменений, показывать их, но не сохранять локально? А если два вызова, оно в состоянии это закэшировать? Юзкейс совершенно непонятен.
Смысл в том, что просматриваемые изменения не попадают в твой репозиторий. Конечно можно потом извратиться и выкинуть их оттуда, но это уже лишние сложности.
N>И пока что я вижу в hg в основном такие хохмы. "Ветки", которые не ветки. "Закладки", которые тем не менее держат на себе состояние репо, хотя по смыслу названия они должны быть просто тегами. Команды с непонятным юзкейсом и заведомо неэффективным стилем исполнения. Зачем всё это?
Да да, вот у меня такое же впечатление от git. ) Вроде как вся базовая функциональность имеется, но всё как-то через задницу. )
Здравствуйте, Cyberax, Вы писали:
C>Я не понимаю сторонников hg. Они массово не понимают как вообще работают DVCS. Git вообще тупой как пробка, там сложного нет ничего. Банально достаточно запомнить, что коммиты образуют цепочку хэшей и всё.
Вообще то все dcvs работают по этому принципу, включая и hg. Только вот поверх этого можно много чего разного накрутить. ) Хотя базовая функциональность действительно одинакова везде, особенно если использовать dcvs только из какой-нибудь IDE.
C>Достаточно уметь это понимать, и всё в git становится понятным.
А кто сказал, что он непонятный? ) Говорят только что неудобный. )
Здравствуйте, netch80, Вы писали:
_>>Текущая ревизия — это понятие глобальное на все файлы, т.е. относится к хранилищу. N>Оно не относится к хранилищу. Оно относится к состоянию рабочей копии. Хранилище при этом не меняется, как бы я ни двигал, какой именно коммит текущий выбранный.
И где в рабочей копии по твоему тогда хранится информация о том, к какой ревизии она относится? )
_>>P.S. Что-то ты в этой темке прямо разошёлся (хотя ничего по делу я так и не увидел, правда и не рассчитывал: выбор между git и mercurial — это реально дело вкуса), N>Когда (см. соседнее сообщение) меня какая-то тулза заставляет переопределить давно устоявшиеся, стандартные по отрасли понятия — это уже не обычное дело вкуса, это bdsm.
С чего ты взял, что давно устоявшиеся? ) Git/Mercurial/Bazaar родились в принципе одновременно и все три могут претендовать на основоположников терминологии. Если же говорить о реально устоявшихся, то это будет скорее SVN и более старые системы — как думаешь, к какой из DVCS их терминология будет ближе? )
Здравствуйте, alex_public, Вы писали:
_>>>- проблема с сохранением истории в git. В mercurial всегда можно найти источник проблемы, а в git'е далеко не всегда. N>>Совершенно непонятно. Что есть "проблема" в данном случае? Источник конкретного изменения? Ищется по истории без проблем, на каждую версию строчки или бинаря есть id коммита, из которого она возникла. Развилки? Они существуют во всех DVCS. _>Даже если забыть о "низкоуровневых" возможностях правки истории в git
Правку истории можно откатить — сами объекты/коммиты не правятся, а создаются новые, так как иммутабельные by-design. Даже если потерять все ссылки на старые коммиты — они всё равно будут ещё жить некоторое время.
), в которых git сильно выигрывает в размере репозитория у своих конкурентов. Правда там мелким шрифтом приписано, что это тестируется после применения repack в git. ))) Ну т.е. если мы после каждого изменения будем делать repack, то тогда git действительно всех обойдёт (правда советую в начале глянуть сколько времени оно занимает). А вот если взглянуть на реальность, то... )))
