Сообщение Re[22]: Git wtf?.. от 06.02.2016 10:39
Изменено 06.02.2016 10:45 netch80
Здравствуйте, alex_public, Вы писали:
_>Здесь https://www.mercurial-scm.org/wiki/Branch всё подробно рассказано.
"The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial." Золотые слова. Вот пока оно будет использоваться, и не под "slightly" разные концепции, а под существенно разные, будет постоянный бардак между ветками, которые специализированные теги коммитов, ветками, которые пучки веток, ветки, которые ещё не слитые ветки (как в твоём ниже про heads) и так далее.
Если этот бардак убрать и нормализовать терминологию, уровень проблем с Hg резко уменьшится, а пользователей таки добавится. Может, и я попробую его в работе
хотя нет, для этого нужен ещё и аналог гитового index с полноценной поддержкой. Вот после этого для меня они будут близки к эквивалентам.
_>Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом). И в результате получают глупости типа описанных в последнем предложение по моей ссылке. )))
Не "пользователи git", не надо натяжек, а все, кто не пришёл к этому "дети, это невозможно понять, но это надо запомнить". Я пытался разобраться с Hg, ещё не зная Git, запутался в этом бардаке, плюнул и забыл. Зато потом с Git было всё просто и понятно.
_>Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем.
Во-во. Тут не ходи, тут рыбу заворачивали...
_>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? )
Да. Это чуть больше работы, но это небольшая цена за внятность концепции.
_>Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? )
`git help gc` рассказывает это. Мегабайт не тот размер, о котором считается осмысленным заботиться (хотя оно считает не по объёму, а по количеству объектов и паков).
С другой стороны, ряд источников говорит "выполняйте gc регулярно в на другой подходящий момент, например, при уходе на обеденный перерыв".
_>Ага, ага http://draketo.de/proj/hg-vs-git-server/test-results.html. Или это слишком сложно и детально? )
Это люди фатально не умеют рисовать графики — за такие рисунки отправлять в третий класс на пересдачу основ. Разбираться в однопиксельных пометках не стал, пошёл сразу к выводам. Пишут, что репо Git в среднем больше, если не начинается много веток, тогда оно меньше. Учитывая типичный стиль работы над действительно большим и серьёзным проектом, где обычно веток много (подготовки релизов, конкретные релизы, трейны апдейтов, параллельные трейны с перетеканием отлаженных фич), это важнее, чем на просто линейной истории.
_> Тогда рекомендую глянуть на такие http://stackoverflow.com/questions/6969385/why-is-my-git-repository-so-much-larger-than-mercurial-version вопросы, периодически возникающие на SO и т.п. местах.
А тут проскакивает, что преимущество Hg в сжатии диффов бинарников. Опять же сомнительное удовольствие (я в рамках благостных пожеланий "а хорошо бы такое увидеть", конечно, хочу, но в реальной жизни как-то не сталкивался — это что ж за бинарники такие, что между версиями можно получить компактный diff?)
_>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии
Что такое bundle?
_>·>"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные.
_>Пакованным они будут до добавления новых ревизий, т.е. очень не долго. )
Они останутся до перепаковки. Новые ревизии добавят новые непакованные объекты, факт. Но старые трогать никто не будет, пока не придёт gc, repack или аналог.
_>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища.
Именно в виде пофайловой копии .git/ — да. Но смысл такого копирования возникает только на репо, которое не может бэкапиться через банальный pull с запретом форсирований операций. А такие, как правило, отражают какие-то спецвиды возни вроде состояний, которые регулярно проходят через upstream rebase — это, например, ветки фида новых коммитов на рассмотрение в корневые репо Linux kernel. Формально проблема есть, практически же её важность крошечна.
_>Здесь https://www.mercurial-scm.org/wiki/Branch всё подробно рассказано.
"The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial." Золотые слова. Вот пока оно будет использоваться, и не под "slightly" разные концепции, а под существенно разные, будет постоянный бардак между ветками, которые специализированные теги коммитов, ветками, которые пучки веток, ветки, которые ещё не слитые ветки (как в твоём ниже про heads) и так далее.
Если этот бардак убрать и нормализовать терминологию, уровень проблем с Hg резко уменьшится, а пользователей таки добавится. Может, и я попробую его в работе
хотя нет, для этого нужен ещё и аналог гитового index с полноценной поддержкой. Вот после этого для меня они будут близки к эквивалентам._>Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом). И в результате получают глупости типа описанных в последнем предложение по моей ссылке. )))
Не "пользователи git", не надо натяжек, а все, кто не пришёл к этому "дети, это невозможно понять, но это надо запомнить". Я пытался разобраться с Hg, ещё не зная Git, запутался в этом бардаке, плюнул и забыл. Зато потом с Git было всё просто и понятно.
_>Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем.
Во-во. Тут не ходи, тут рыбу заворачивали...
_>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? )
Да. Это чуть больше работы, но это небольшая цена за внятность концепции.
_>Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? )
`git help gc` рассказывает это. Мегабайт не тот размер, о котором считается осмысленным заботиться (хотя оно считает не по объёму, а по количеству объектов и паков).
С другой стороны, ряд источников говорит "выполняйте gc регулярно в на другой подходящий момент, например, при уходе на обеденный перерыв".
_>Ага, ага http://draketo.de/proj/hg-vs-git-server/test-results.html. Или это слишком сложно и детально? )
Это люди фатально не умеют рисовать графики — за такие рисунки отправлять в третий класс на пересдачу основ. Разбираться в однопиксельных пометках не стал, пошёл сразу к выводам. Пишут, что репо Git в среднем больше, если не начинается много веток, тогда оно меньше. Учитывая типичный стиль работы над действительно большим и серьёзным проектом, где обычно веток много (подготовки релизов, конкретные релизы, трейны апдейтов, параллельные трейны с перетеканием отлаженных фич), это важнее, чем на просто линейной истории.
_> Тогда рекомендую глянуть на такие http://stackoverflow.com/questions/6969385/why-is-my-git-repository-so-much-larger-than-mercurial-version вопросы, периодически возникающие на SO и т.п. местах.
А тут проскакивает, что преимущество Hg в сжатии диффов бинарников. Опять же сомнительное удовольствие (я в рамках благостных пожеланий "а хорошо бы такое увидеть", конечно, хочу, но в реальной жизни как-то не сталкивался — это что ж за бинарники такие, что между версиями можно получить компактный diff?)
_>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии
Что такое bundle?
_>·>"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные.
_>Пакованным они будут до добавления новых ревизий, т.е. очень не долго. )
Они останутся до перепаковки. Новые ревизии добавят новые непакованные объекты, факт. Но старые трогать никто не будет, пока не придёт gc, repack или аналог.
_>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища.
Именно в виде пофайловой копии .git/ — да. Но смысл такого копирования возникает только на репо, которое не может бэкапиться через банальный pull с запретом форсирований операций. А такие, как правило, отражают какие-то спецвиды возни вроде состояний, которые регулярно проходят через upstream rebase — это, например, ветки фида новых коммитов на рассмотрение в корневые репо Linux kernel. Формально проблема есть, практически же её важность крошечна.
Re[22]: Git wtf?..
Здравствуйте, alex_public, Вы писали:
_>Здесь https://www.mercurial-scm.org/wiki/Branch всё подробно рассказано.
"The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial." Золотые слова. Вот пока оно будет использоваться, и не под "slightly" разные концепции, а под существенно разные, будет постоянный бардак между ветками, которые специализированные теги коммитов, ветками, которые пучки веток, ветки, которые ещё не слитые ветки (как в твоём ниже про heads) и так далее.
Если этот бардак убрать и нормализовать терминологию, уровень проблем с Hg резко уменьшится, а пользователей таки добавится. Может, и я попробую его в работе хотя нет, для этого нужен ещё и аналог гитового index с полноценной поддержкой, и interactive rebase с его возможностями по расщеплению, слиянию и перестановке коммитов, модификации батчем. Вот после этого для меня они будут близки к эквивалентам.
_>Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом). И в результате получают глупости типа описанных в последнем предложение по моей ссылке. )))
Не "пользователи git", не надо натяжек, а все, кто не пришёл к этому "дети, это невозможно понять, но это надо запомнить". Я пытался разобраться с Hg, ещё не зная Git, запутался в этом бардаке, плюнул и забыл. Зато потом с Git было всё просто и понятно.
_>Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем.
Во-во. Тут не ходи, тут рыбу заворачивали...
_>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? )
Да. Это чуть больше работы, но это небольшая цена за внятность концепции.
_>Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? )
`git help gc` рассказывает это. Мегабайт не тот размер, о котором считается осмысленным заботиться (хотя оно считает не по объёму, а по количеству объектов и паков).
С другой стороны, ряд источников говорит "выполняйте gc регулярно в на другой подходящий момент, например, при уходе на обеденный перерыв".
_>Ага, ага http://draketo.de/proj/hg-vs-git-server/test-results.html. Или это слишком сложно и детально? )
Это люди фатально не умеют рисовать графики — за такие рисунки отправлять в третий класс на пересдачу основ. Разбираться в однопиксельных пометках не стал, пошёл сразу к выводам. Пишут, что репо Git в среднем больше, если не начинается много веток, тогда оно меньше. Учитывая типичный стиль работы над действительно большим и серьёзным проектом, где обычно веток много (подготовки релизов, конкретные релизы, трейны апдейтов, параллельные трейны с перетеканием отлаженных фич), это важнее, чем на просто линейной истории.
_> Тогда рекомендую глянуть на такие http://stackoverflow.com/questions/6969385/why-is-my-git-repository-so-much-larger-than-mercurial-version вопросы, периодически возникающие на SO и т.п. местах.
А тут проскакивает, что преимущество Hg в сжатии диффов бинарников. Опять же сомнительное удовольствие (я в рамках благостных пожеланий "а хорошо бы такое увидеть", конечно, хочу, но в реальной жизни как-то не сталкивался — это что ж за бинарники такие, что между версиями можно получить компактный diff?)
_>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии
Что такое bundle?
_>·>"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные.
_>Пакованным они будут до добавления новых ревизий, т.е. очень не долго. )
Они останутся до перепаковки. Новые ревизии добавят новые непакованные объекты, факт. Но старые трогать никто не будет, пока не придёт gc, repack или аналог.
_>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища.
Именно в виде пофайловой копии .git/ — да. Но смысл такого копирования возникает только на репо, которое не может бэкапиться через банальный pull с запретом форсирований операций. А такие, как правило, отражают какие-то спецвиды возни вроде состояний, которые регулярно проходят через upstream rebase — это, например, ветки фида новых коммитов на рассмотрение в корневые репо Linux kernel. Формально проблема есть, практически же её важность крошечна.
_>Здесь https://www.mercurial-scm.org/wiki/Branch всё подробно рассказано.
"The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial." Золотые слова. Вот пока оно будет использоваться, и не под "slightly" разные концепции, а под существенно разные, будет постоянный бардак между ветками, которые специализированные теги коммитов, ветками, которые пучки веток, ветки, которые ещё не слитые ветки (как в твоём ниже про heads) и так далее.
Если этот бардак убрать и нормализовать терминологию, уровень проблем с Hg резко уменьшится, а пользователей таки добавится. Может, и я попробую его в работе
хотя нет, для этого нужен ещё и аналог гитового index с полноценной поддержкой, и interactive rebase с его возможностями по расщеплению, слиянию и перестановке коммитов, модификации батчем. Вот после этого для меня они будут близки к эквивалентам._>Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом). И в результате получают глупости типа описанных в последнем предложение по моей ссылке. )))
Не "пользователи git", не надо натяжек, а все, кто не пришёл к этому "дети, это невозможно понять, но это надо запомнить". Я пытался разобраться с Hg, ещё не зная Git, запутался в этом бардаке, плюнул и забыл. Зато потом с Git было всё просто и понятно.
_>Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем.
Во-во. Тут не ходи, тут рыбу заворачивали...
_>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? )
Да. Это чуть больше работы, но это небольшая цена за внятность концепции.
_>Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? )
`git help gc` рассказывает это. Мегабайт не тот размер, о котором считается осмысленным заботиться (хотя оно считает не по объёму, а по количеству объектов и паков).
С другой стороны, ряд источников говорит "выполняйте gc регулярно в на другой подходящий момент, например, при уходе на обеденный перерыв".
_>Ага, ага http://draketo.de/proj/hg-vs-git-server/test-results.html. Или это слишком сложно и детально? )
Это люди фатально не умеют рисовать графики — за такие рисунки отправлять в третий класс на пересдачу основ. Разбираться в однопиксельных пометках не стал, пошёл сразу к выводам. Пишут, что репо Git в среднем больше, если не начинается много веток, тогда оно меньше. Учитывая типичный стиль работы над действительно большим и серьёзным проектом, где обычно веток много (подготовки релизов, конкретные релизы, трейны апдейтов, параллельные трейны с перетеканием отлаженных фич), это важнее, чем на просто линейной истории.
_> Тогда рекомендую глянуть на такие http://stackoverflow.com/questions/6969385/why-is-my-git-repository-so-much-larger-than-mercurial-version вопросы, периодически возникающие на SO и т.п. местах.
А тут проскакивает, что преимущество Hg в сжатии диффов бинарников. Опять же сомнительное удовольствие (я в рамках благостных пожеланий "а хорошо бы такое увидеть", конечно, хочу, но в реальной жизни как-то не сталкивался — это что ж за бинарники такие, что между версиями можно получить компактный diff?)
_>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии
Что такое bundle?
_>·>"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные.
_>Пакованным они будут до добавления новых ревизий, т.е. очень не долго. )
Они останутся до перепаковки. Новые ревизии добавят новые непакованные объекты, факт. Но старые трогать никто не будет, пока не придёт gc, repack или аналог.
_>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища.
Именно в виде пофайловой копии .git/ — да. Но смысл такого копирования возникает только на репо, которое не может бэкапиться через банальный pull с запретом форсирований операций. А такие, как правило, отражают какие-то спецвиды возни вроде состояний, которые регулярно проходят через upstream rebase — это, например, ветки фида новых коммитов на рассмотрение в корневые репо Linux kernel. Формально проблема есть, практически же её важность крошечна.