java development cluster
1) Если вы не против работать в виртуалке, то vagrant как раз для этого
2) Тут вагрант уже немного не в тему, нужен скорее puppet. Можно docker, но это немного в другую сторону. Это все не готовые решения, а что-то, что надо будет сильно допиливать. Решений из коробки в опенсорсе я не видел.
3) На среду по хорошему не должно быть завязок. Любой чел должен иметь возможность поставить свою среду и без проблем на ней писать. С файндбагсом и ему подобным аккуратнее - он там параноидален местами, но так, поначалу, узнаешь много нового.
В гит упираться если планируются фичебранчи. Если же нет, то можно и оставить, конечно... У очень многих людей переход от centralised к distributed упирается в какой-то барьер, который они не хотят преодолевать. Если чуваки молодые, то я б настоял, пожалуй. Нефиг, рано им еще.
2) Тут вагрант уже немного не в тему, нужен скорее puppet. Можно docker, но это немного в другую сторону. Это все не готовые решения, а что-то, что надо будет сильно допиливать. Решений из коробки в опенсорсе я не видел.
3) На среду по хорошему не должно быть завязок. Любой чел должен иметь возможность поставить свою среду и без проблем на ней писать. С файндбагсом и ему подобным аккуратнее - он там параноидален местами, но так, поначалу, узнаешь много нового.
В гит упираться если планируются фичебранчи. Если же нет, то можно и оставить, конечно... У очень многих людей переход от centralised к distributed упирается в какой-то барьер, который они не хотят преодолевать. Если чуваки молодые, то я б настоял, пожалуй. Нефиг, рано им еще.
bigdateРади интереса, с какого объема сейчас считается что началась бигдата?
На среду по хорошему не должно быть завязокТам же gradle в списке - думаю, это подразумевает, что завязок не будет
+1 за гит, если планируются ветки. К тому же не знаю, как в Эклипс, а в Idea настолько удобная (и довольно унифицированная) работа со средствами контроля версий, что для повседневных задач переход с SVN будет даже практически незаметен.
> 3) (холиворное) intellij idea (eclipse мне неудобен gradle,
> jenkins, svn (хочу git, но другие чуваки в команде упираются
> и хотят svn, не знаю, упираться ли рогами мне findbugs.
> Все годится? Что еще забыто?
Каждый должен быть способен использовать свою IDE, не надо
бороться с тем, как человек организует свой участок работы.
Некоторым очень не нравится Jenkins, они предпочитают buildbot,
но если у тебя всюду ява, то, возможно, это не стоит.
git в топку, сразу и окончательно. Те, кто хотят Subversion, правы.
И это никак не относится к тому, распределённый он или нет,
на Bazaar или Mercurial такие люди переходят очень просто.
---
Q5: а нафига A4?
A5: чтоб сосать.
> jenkins, svn (хочу git, но другие чуваки в команде упираются
> и хотят svn, не знаю, упираться ли рогами мне findbugs.
> Все годится? Что еще забыто?
Каждый должен быть способен использовать свою IDE, не надо
бороться с тем, как человек организует свой участок работы.
Некоторым очень не нравится Jenkins, они предпочитают buildbot,
но если у тебя всюду ява, то, возможно, это не стоит.
git в топку, сразу и окончательно. Те, кто хотят Subversion, правы.
И это никак не относится к тому, распределённый он или нет,
на Bazaar или Mercurial такие люди переходят очень просто.
---
Q5: а нафига A4?
A5: чтоб сосать.
хочу git, но другие чуваки в команде упираются и хотят svn, не знаю, упираться ли рогами мнеГони их в шею!
В крайнем случае можно меркуриал в качестве компромисса.
А в чём здесь компромис? Если он один хочет с гитом, пусть работает с гитом и пушит в svn
А ответь мне, есть ли у свн-а вёб клиент, и всякие прочие радости жизни типа человеческого мёрджа?
А ответь мне, есть ли у свн-а вёб клиентА зачем тебе веб-клиент?
Не мне, а ПМ и аналитикам. Они боятся консольной строки. Ну и плюс проверить, что всё ок запушилось.
Не мне, а ПМ и аналитикам. Они боятся консольной строки.отличный гуевый клиент tortoisesvn же есть
> А ответь мне, есть ли у свн-а вёб клиент,
Есть.
> и всякие прочие радости жизни типа человеческого мёрджа?
Прочих радостей у Subversion значительно больше.
В частности, более человеческая работа с ветками,
оно хотя бы не пытается склеивать usr.bin/head/head.1
с games/pom/pom.6
---
"Разжигание флейма.
Если хорошо получилось, то хорошо. Иначе плохо."
Есть.
> и всякие прочие радости жизни типа человеческого мёрджа?
Прочих радостей у Subversion значительно больше.
В частности, более человеческая работа с ветками,
оно хотя бы не пытается склеивать usr.bin/head/head.1
с games/pom/pom.6
---
"Разжигание флейма.
Если хорошо получилось, то хорошо. Иначе плохо."
Я имел ввиду, что для svn-щиков что git, что hg - примерно один хер. И компромиса тут нет, страдают все.
> Я имел ввиду, что для svn-щиков что git, что hg - примерно один хер.
Гон.
---
"Унивеpситет pазвивает все способности, в том числе --- глупость."
Гон.
---
"Унивеpситет pазвивает все способности, в том числе --- глупость."
А кстати в чём проявляется человечность свновских веток по сравнению с гитовыми, и что за склеивание веток? По-моему, наоборот, свновский пофайловый чекаут это какая-то дичь, условно сопоставимая с отказом от VCS ("типа кинь мне по почте новые версии файлов которые ты поменял, а те которые не менял не кидай").
Вообще из критики гита мне нравится вот этот образец http://stevelosh.com/blog/2013/04/git-koans/, но он довольно лёгкий (типа, новичку будет тяжело если он отклонится от проторенного воркфлоу, ну так это много где верно).
Вообще из критики гита мне нравится вот этот образец http://stevelosh.com/blog/2013/04/git-koans/, но он довольно лёгкий (типа, новичку будет тяжело если он отклонится от проторенного воркфлоу, ну так это много где верно).
> типа, новичку будет тяжело если он отклонится от проторенного
> воркфлоу, ну так это много где верно
Гон. Проблема в том, что этих несуразностей наворочено выше головы,
а самое главное --- существуют ошибочные состояния системы, куда
попадаешь из-за опечатки, а выйти из них можно только какими-то
низкоуровневыми хаками.
Более того, новичок может по ошибке удалить из общего репозитория
день работы нескольких человек, из-за того, что "push" может
перезаписать историю. Причём сами обгитованные могут не понять,
почему это произошло.
> По-моему, наоборот, свновский пофайловый чекаут это какая-то дичь,
> условно сопоставимая с отказом от VCS ("типа кинь мне по почте
> новые версии файлов которые ты поменял, а те которые не менял
> не кидай").
Все файлы, которые ты извлёк, они находятся под управлением VCS.
Ты можешь выполнять с ними все те же действия: сравнивать, изменять,
склеивать и так далее. Где дичь-то? Дичь --- это когда для изменения
одной строки тебе надо тащить полтора гига репозитория.
> А кстати в чём проявляется человечность свновских веток
> по сравнению с гитовыми, и что за склеивание веток?
В том, что к ним сделан однородный и понятный доступ.
О, да, кстати, "vendor branch" в гите вообще очень прикольно
реализуется. Самое главное --- фиг объяснишь обгитованным,
что ты хочешь. Судя по всему, они вообще не понимают,
почему ты хочешь отслеживать изменения в чужом коде
и только потом вносить их в свой.
---
"Narrowness of experience leads to narrowness of imagination."
> воркфлоу, ну так это много где верно
Гон. Проблема в том, что этих несуразностей наворочено выше головы,
а самое главное --- существуют ошибочные состояния системы, куда
попадаешь из-за опечатки, а выйти из них можно только какими-то
низкоуровневыми хаками.
Более того, новичок может по ошибке удалить из общего репозитория
день работы нескольких человек, из-за того, что "push" может
перезаписать историю. Причём сами обгитованные могут не понять,
почему это произошло.
> По-моему, наоборот, свновский пофайловый чекаут это какая-то дичь,
> условно сопоставимая с отказом от VCS ("типа кинь мне по почте
> новые версии файлов которые ты поменял, а те которые не менял
> не кидай").
Все файлы, которые ты извлёк, они находятся под управлением VCS.
Ты можешь выполнять с ними все те же действия: сравнивать, изменять,
склеивать и так далее. Где дичь-то? Дичь --- это когда для изменения
одной строки тебе надо тащить полтора гига репозитория.
> А кстати в чём проявляется человечность свновских веток
> по сравнению с гитовыми, и что за склеивание веток?
В том, что к ним сделан однородный и понятный доступ.
О, да, кстати, "vendor branch" в гите вообще очень прикольно
реализуется. Самое главное --- фиг объяснишь обгитованным,
что ты хочешь. Судя по всему, они вообще не понимают,
почему ты хочешь отслеживать изменения в чужом коде
и только потом вносить их в свой.
---
"Narrowness of experience leads to narrowness of imagination."
отличный гуевый клиент tortoisesvn же естьу нас админские права на машине только у программистов.
Гон. Проблема в том, что этих несуразностей наворочено выше головы,А я считаю, что гит довольно красив и консистентен. Нюансов там может быть много, но при этом, раз построив себе картинку в голове как оно работает в целом, ты можешь легко предсказывать его поведение в различных ситуациях.
а самое главное --- существуют ошибочные состояния системы, куда
попадаешь из-за опечатки, а выйти из них можно только какими-то
низкоуровневыми хаками.
Можешь пояснить, что для тебя является низкоуровневыми хаками?
Пока это все выглядит как "бла-бла-бла, я не умею готовить гит, бла-бла-бла".
Более того, новичок может по ошибке удалить из общего репозиторияБла-бла-бла, у нас никто не потрудился настроить гит-сервер, и никто не понимает гит, и не читает что он пишет при пуше, все только ноют, бла-бла-бла.
день работы нескольких человек, из-за того, что "push" может
перезаписать историю. Причём сами обгитованные могут не понять,
почему это произошло.
Где дичь-то?Дичь в том, что мердж свна неплохо работает только в одном случае - когда из фичебранч все мерджится в trunk ровно один раз, когда фича закончена.
Если ты, работая в фичебранче, захочешь обновиться из транка, поработать над фичей еще немного, и только потом зафигачить это в trunk, или не дай бог смерджиться с фичебранчей коллеги, то ты обречен на merge day'и. (на самом деле, тебе приходится выбирать между частыми коммитами со сломанным trunk'ом и merge day).
Мердж в svn это в принципе один большой костыль, который в хоть сколько-то удобоваримом виде появился аж в 1.5, и у которого принципиально нет шансов нормально работать, потому что у него каждый патчсет при мердже превращается в новую сущность, и нет механизма для отслеживания этого. Есть только замечательное решение в виде svn:mergeinfo, которое очень быстро превращается в ужастик, который сам нужно ручками как-то мерджить (хахаха).
Как один из примеров особенного рода ужастика - это когда кто-то померджит в бранчах только какую-то подпапочку, тем самым добавив еще один svn:mergeinfo на этой подпапочке. В этот момент весь костыль разваливается окончательно, а merge day элегантным мановением руки превращается в merge week.
В том, что к ним сделан однородный и понятный доступ.Чтооо? Отдельная папочка branches (или как повезет) - это однородный и понятный доступ?
Умолчим об огромном оверхеде на создание новой ветки и переключение между ними, который следует из такой "однородности".
О, да, кстати, "vendor branch" в гите вообще очень прикольноУ меня это просто еще один ремоут. А у вас?
реализуется.
Самое главное --- фиг объяснишь обгитованным,Давай ты попробуешь сначала объяснить нам что ты хочешь, прежде чем кидаться такими утверждениями.
что ты хочешь. Судя по всему, они вообще не понимают,
почему ты хочешь отслеживать изменения в чужом коде
и только потом вносить их в свой.
Пока это все звучит как что-то вроде "я хочу уметь научиться пользоваться 'git log mybranch..vendorbranch' и 'git diff'", и непонятно, что тебе мешает.
Дичь --- это когда для изменения одной строки тебе надо тащить полтора гига репозитория.Все очень любят в это тыкать, но как-то не учитывают, что
1) initial checkout - редкая операция, и даже на таком большом проекте как linux, это съедает всего 200мег траффика, что на сегодняшних каналах просто смешно и доступно даже on-the-go через сраный hspa. branch switch/checkout - частая операция, и тут svn сосет, прокачивая одни и те же файлы снова и снова, причем сосет не только с ростом суммарного объема trunk'а, но и с ростом кол-ва файлов (один запрос на один файл в случае http - включил чекаут бранча, и пошел пить кофе).
2) в гите есть deduplication/compression на уровне блобов и их частей
3) С учетом 2 если у вас столько бинарников в репе, что она занимает полтора гига, то вы, во-первых, ссзб-уникуум, во-вторых, каждое бранчевание этого дела в svn, вероятно, занимало вечность.
В итоге, сейчас гит для меня лучше в плане траффика и пефоманса на порядок.
В гите есть недостатки, в чем-то продиктованные децентрализованностью, типа невозможности залочить файл, или отсутствия централизованного места, где можно посмотреть кто над чем работает, но этого, извините, и в дефолтном свне нету.
> Проблема в том, что этих несуразностей наворочено выше головы,
> а самое главное --- существуют ошибочные состояния системы, куда
> попадаешь из-за опечатки, а выйти из них можно только какими-то
> низкоуровневыми хаками.
Это несомненно так, если смотреть на эти коаны или на документацию.
Команды неортогональные и через жопу.
А на практике насколько это типично?
Я например пользуюсь гитом порядочно, в варьирующихся контекстах,
но случайно привести репозиторий в особенно непонятное состояние
получалось весьма редко. И стрёмные вариации всяких команд нужны
редко.
> Более того, новичок может по ошибке удалить из общего репозитория
> день работы нескольких человек, из-за того, что "push" может
> перезаписать историю. Причём сами обгитованные могут не понять,
> почему это произошло.
Ну совсем случайно это не сделаешь.
Хотя да, печально что в гитхабе например нельзя запретить форс пуш
(в гите в общем случае - можно).
> Где дичь-то? Дичь --- это когда для изменения
> одной строки тебе надо тащить полтора гига репозитория.
Дичь в неатомарности ревизии, что вызывает желание сэкономить и
апдейтить только то что (как тебе кажется) поменялось, и в итоге
состояние рабочего каталога оказывается химерой. И я пару раз видел как люди
например тестировали не то что они думали что тестируют, именно поэтому.
Ок допустим для вендор бранчей действительно хочетя манипулировать историей
независимо. Но обычные подкаталоги и файлы тут при чём?
> тащить полтора гига репозитория
Ну может в этих полутора гигабайтах находятся ещё тесты которые стоило бы
прогнать. Ну или там посмотреть скомпилируется код или нет.
> > А кстати в чём проявляется человечность свновских веток
> > по сравнению с гитовыми, и что за склеивание веток?
> В том, что к ним сделан однородный и понятный доступ.
Это не выглядит как ответ.
> О, да, кстати, "vendor branch" в гите вообще очень прикольно
реализуется.
И по-моему это справедливо, потому что концепция действительно
нетривиальная (и вполне возможно что потребует поведения,
специфического для проекта). Вот например я сталкивался
с ситуацией где зависимости между репозиториями имели циклы.
Было бы конечно неплохо иметь какое-нибудь стандартное решение,
но тогда оно как минимум должно быть vcs-agnostic. Потому что всех
вендоров на svn не переведёшь, вот даже ты например
в силу каких-то странных причин терпишь hg.
> "Narrowness of experience leads to narrowness of imagination."
Действительно, cvs и svn я пользовался не очень много и довольно давно. И нахуй их.
> а самое главное --- существуют ошибочные состояния системы, куда
> попадаешь из-за опечатки, а выйти из них можно только какими-то
> низкоуровневыми хаками.
Это несомненно так, если смотреть на эти коаны или на документацию.
Команды неортогональные и через жопу.
А на практике насколько это типично?
Я например пользуюсь гитом порядочно, в варьирующихся контекстах,
но случайно привести репозиторий в особенно непонятное состояние
получалось весьма редко. И стрёмные вариации всяких команд нужны
редко.
> Более того, новичок может по ошибке удалить из общего репозитория
> день работы нескольких человек, из-за того, что "push" может
> перезаписать историю. Причём сами обгитованные могут не понять,
> почему это произошло.
Ну совсем случайно это не сделаешь.
Хотя да, печально что в гитхабе например нельзя запретить форс пуш
(в гите в общем случае - можно).
> Где дичь-то? Дичь --- это когда для изменения
> одной строки тебе надо тащить полтора гига репозитория.
Дичь в неатомарности ревизии, что вызывает желание сэкономить и
апдейтить только то что (как тебе кажется) поменялось, и в итоге
состояние рабочего каталога оказывается химерой. И я пару раз видел как люди
например тестировали не то что они думали что тестируют, именно поэтому.
Ок допустим для вендор бранчей действительно хочетя манипулировать историей
независимо. Но обычные подкаталоги и файлы тут при чём?
> тащить полтора гига репозитория
Ну может в этих полутора гигабайтах находятся ещё тесты которые стоило бы
прогнать. Ну или там посмотреть скомпилируется код или нет.
> > А кстати в чём проявляется человечность свновских веток
> > по сравнению с гитовыми, и что за склеивание веток?
> В том, что к ним сделан однородный и понятный доступ.
Это не выглядит как ответ.
> О, да, кстати, "vendor branch" в гите вообще очень прикольно
реализуется.
И по-моему это справедливо, потому что концепция действительно
нетривиальная (и вполне возможно что потребует поведения,
специфического для проекта). Вот например я сталкивался
с ситуацией где зависимости между репозиториями имели циклы.
Было бы конечно неплохо иметь какое-нибудь стандартное решение,
но тогда оно как минимум должно быть vcs-agnostic. Потому что всех
вендоров на svn не переведёшь, вот даже ты например
в силу каких-то странных причин терпишь hg.
> "Narrowness of experience leads to narrowness of imagination."
Действительно, cvs и svn я пользовался не очень много и довольно давно. И нахуй их.
> Это несомненно так, если смотреть на эти коаны или на документацию.
А есть другие способы узнать, как выполнить какую-то определённую
операцию, которую ты представляешь как сделать, но ни разу ещё
не делал с гитом?
> Команды неортогональные и через жопу.
> А на практике насколько это типично?
Для гита --- очень типично. В особенности, когда у тебя есть
сотрудники, для которых любая система управления версиями
является новшевством (им у нас пока ещё ни в каких институтах
не учат). Почему-то остальные системы управления версиями имеют
более вменяемую систему команд.
> Я например пользуюсь гитом порядочно, в варьирующихся контекстах,
> но случайно привести репозиторий в особенно непонятное состояние
> получалось весьма редко. И стрёмные вариации всяких команд нужны
> редко.
С гитом даже при попытке вытащить конкретную версию ты
оказываешься в особенно непонятном состоянии, когда закоммитить
ты можешь, но все твои изменения будут, по сути, выкинуты в мусор,
>> Более того, новичок может по ошибке удалить из общего репозитория
>> день работы нескольких человек, из-за того, что "push" может
>> перезаписать историю. Причём сами обгитованные могут не понять,
>> почему это произошло.
> Ну совсем случайно это не сделаешь.
А что для тебя значит "совсем" применительно к случайно?
Я знаю пример, когда это было сделано совсем случайно,
причём человек честно пытался использовать гит как
распределённую систему.
Не должна система управления версиями удалять метку, если этого
изменения не было произведено в явном виде. А гит это позволяет
сделать, причём именно при использовании распределённого подхода,
если работать с ним как с централизованной системой, то всё в
порядке.
>> Где дичь-то? Дичь --- это когда для изменения
>> одной строки тебе надо тащить полтора гига репозитория.
> Дичь в неатомарности ревизии, что вызывает желание сэкономить и
> апдейтить только то что (как тебе кажется) поменялось, и в итоге
> состояние рабочего каталога оказывается химерой.
> И я пару раз видел как люди например тестировали не то что они
> думали что тестируют, именно поэтому.
Неатомарности здесь никакой нет. Гит не мешает тебе поменять
два файла, а закоммитить только один из них.
>> тащить полтора гига репозитория
> Ну может в этих полутора гигабайтах находятся ещё тесты
> которые стоило бы прогнать. Ну или там посмотреть
> скомпилируется код или нет.
А без "ну, может"? Нет там никаких тестов, всё уже прогнано,
осталось поменять одну строку.
>> О, да, кстати, "vendor branch" в гите вообще очень прикольно
>> реализуется.
> И по-моему это справедливо, потому что концепция действительно
> нетривиальная (и вполне возможно что потребует поведения,
> специфического для проекта). Вот например я сталкивался
> с ситуацией где зависимости между репозиториями имели циклы.
Эта нетривиальная концепция использовалась и используется
во всех проектах с моим участием. Почему-то в CVS и Subversion
она реализована.
> Было бы конечно неплохо иметь какое-нибудь стандартное решение,
> но тогда оно как минимум должно быть vcs-agnostic. Потому что всех
> вендоров на svn не переведёшь, вот даже ты например
> в силу каких-то странных причин терпишь hg.
Я и с гитом могу работать, но когда я вижу, что CVS склеивает
ветки лучше, то у меня возникает соответствующее отношение к LT
и его последователям.
---
Q5: а нафига A4?
A5: чтоб сосать.
А есть другие способы узнать, как выполнить какую-то определённую
операцию, которую ты представляешь как сделать, но ни разу ещё
не делал с гитом?
> Команды неортогональные и через жопу.
> А на практике насколько это типично?
Для гита --- очень типично. В особенности, когда у тебя есть
сотрудники, для которых любая система управления версиями
является новшевством (им у нас пока ещё ни в каких институтах
не учат). Почему-то остальные системы управления версиями имеют
более вменяемую систему команд.
> Я например пользуюсь гитом порядочно, в варьирующихся контекстах,
> но случайно привести репозиторий в особенно непонятное состояние
> получалось весьма редко. И стрёмные вариации всяких команд нужны
> редко.
С гитом даже при попытке вытащить конкретную версию ты
оказываешься в особенно непонятном состоянии, когда закоммитить
ты можешь, но все твои изменения будут, по сути, выкинуты в мусор,
>> Более того, новичок может по ошибке удалить из общего репозитория
>> день работы нескольких человек, из-за того, что "push" может
>> перезаписать историю. Причём сами обгитованные могут не понять,
>> почему это произошло.
> Ну совсем случайно это не сделаешь.
А что для тебя значит "совсем" применительно к случайно?
Я знаю пример, когда это было сделано совсем случайно,
причём человек честно пытался использовать гит как
распределённую систему.
Не должна система управления версиями удалять метку, если этого
изменения не было произведено в явном виде. А гит это позволяет
сделать, причём именно при использовании распределённого подхода,
если работать с ним как с централизованной системой, то всё в
порядке.
>> Где дичь-то? Дичь --- это когда для изменения
>> одной строки тебе надо тащить полтора гига репозитория.
> Дичь в неатомарности ревизии, что вызывает желание сэкономить и
> апдейтить только то что (как тебе кажется) поменялось, и в итоге
> состояние рабочего каталога оказывается химерой.
> И я пару раз видел как люди например тестировали не то что они
> думали что тестируют, именно поэтому.
Неатомарности здесь никакой нет. Гит не мешает тебе поменять
два файла, а закоммитить только один из них.
>> тащить полтора гига репозитория
> Ну может в этих полутора гигабайтах находятся ещё тесты
> которые стоило бы прогнать. Ну или там посмотреть
> скомпилируется код или нет.
А без "ну, может"? Нет там никаких тестов, всё уже прогнано,
осталось поменять одну строку.
>> О, да, кстати, "vendor branch" в гите вообще очень прикольно
>> реализуется.
> И по-моему это справедливо, потому что концепция действительно
> нетривиальная (и вполне возможно что потребует поведения,
> специфического для проекта). Вот например я сталкивался
> с ситуацией где зависимости между репозиториями имели циклы.
Эта нетривиальная концепция использовалась и используется
во всех проектах с моим участием. Почему-то в CVS и Subversion
она реализована.
> Было бы конечно неплохо иметь какое-нибудь стандартное решение,
> но тогда оно как минимум должно быть vcs-agnostic. Потому что всех
> вендоров на svn не переведёшь, вот даже ты например
> в силу каких-то странных причин терпишь hg.
Я и с гитом могу работать, но когда я вижу, что CVS склеивает
ветки лучше, то у меня возникает соответствующее отношение к LT
и его последователям.
---
Q5: а нафига A4?
A5: чтоб сосать.
> Бла-бла-бла, у нас никто не потрудился настроить гит-сервер,
> и никто не понимает гит, и не читает что он пишет при пуше,
> все только ноют, бла-бла-бла.
То есть, чтобы "система управления версиями" не теряла коммиты,
её надо как-то специально подстраивать. А патчить её не надо?
>> О, да, кстати, "vendor branch" в гите вообще очень прикольно
>> реализуется.
> У меня это просто еще один ремоут. А у вас?
И куда он указывает, если вендор прислал тебе архивчик?
Что с ним происходит, когда ты клонируешь репозиторий?
Вот-вот.
> 1) initial checkout - редкая операция,
А просто выписка у тебя редкая операция?
> и даже на таком большом проекте как linux
Линух --- большой проект!
> В гите есть недостатки, в чем-то продиктованные
> децентрализованностью,
Почему ни "меркуриал," ни "базаар," ни фоссил не обладают
большей частью из этих недостатков? Они внезапно перестали
быть распределёнными?
---
A40: Так завещел великий и мудрый LT и по другому называть некошерно.
> и никто не понимает гит, и не читает что он пишет при пуше,
> все только ноют, бла-бла-бла.
То есть, чтобы "система управления версиями" не теряла коммиты,
её надо как-то специально подстраивать. А патчить её не надо?
>> О, да, кстати, "vendor branch" в гите вообще очень прикольно
>> реализуется.
> У меня это просто еще один ремоут. А у вас?
И куда он указывает, если вендор прислал тебе архивчик?
Что с ним происходит, когда ты клонируешь репозиторий?
Вот-вот.
> 1) initial checkout - редкая операция,
А просто выписка у тебя редкая операция?
> и даже на таком большом проекте как linux
Линух --- большой проект!
> В гите есть недостатки, в чем-то продиктованные
> децентрализованностью,
Почему ни "меркуриал," ни "базаар," ни фоссил не обладают
большей частью из этих недостатков? Они внезапно перестали
быть распределёнными?
---
A40: Так завещел великий и мудрый LT и по другому называть некошерно.
То есть, чтобы "система управления версиями" не теряла коммиты,Как вариант, еще достаточно иметь мозг и читать что тебе пишут. И если мозга нет или не умеешь читать - то тогда уже да, придется специально ее настроить.
её надо как-то специально подстраивать. А патчить её не надо?
Можно еще, конечно, проповедовать всем палочки для еды и заставлять поваров все мелко рубить, аргументируя это тем, что острые ножи чересчур опасны, как это делаешь ты. При этом я бы не удивлялся, если некоторые люди будут тебя, ммм, вежливо сторониться.
И куда он указывает, если вендор прислал тебе архивчик?Что вот-вот? В каком-нибудь свне с этим как-то проще внезапно стало?
Что с ним происходит, когда ты клонируешь репозиторий?
Вот-вот.
Я помню, в свн буке раньше прилагался для этих целей непонятно кем поддерживаемый перл скрипт, который импортировывал такие архивчики с попыткой найти и захендлить перемещения файлов. Через пару часов обезьяней работы у тебя, возможно, что-то получалось.
А просто выписка у тебя редкая операция?git clone? Да, редкая. Даже несмотря на то, что у нас по репозиторию на каждый модуль, и модули очень мелкие, иногда всего несколько файлов.
Реально больших реп не так уж много в этом мире, знаешь ли. Особенно опен-сурса.
Так уж тут по-любому что-то одно - или ты часто клонишь мелкие репы, или редко, но большие.
Линух --- большой проект!С 15М LoC и 30 годами истории? Ну да, я думаю, что побольше большинства существующих, где-то в p99.999 примерно, я думаю. У тебя какие-то другие оценки?
Почему ни "меркуриал," ни "базаар," ни фоссил не обладаютТы о каком недостатке сейчас? Об отсутствии локов?
большей частью из этих недостатков? Они внезапно перестали
быть распределёнными?
git
fossil
mercurial
bazaar
Итого, только меркуриал упоминает на своем сайте о том, что надо, с пометкой, что это всего лишь расширение.
К гиту такое расширение тоже можно найти, может и к остальным системам можно, если аккуратно копаться, но мне лень уже.
Кстати, если погуглить еще, то можно понять, что вообще-то есть centralized и decentralized workflow, они противопоставляются друг другу даже в случае приводимого тобой как эталона базаара, и последний как-то не особо предполагает наличие локов.
Вообще, на моей памяти, механизм локов в мало-мальски большой команде обычно старались не использовать (читай, никогда не использовали ибо смерджить обычно даже в случае всяких свнов проще, чем бегать за n людьми с просьбами отпустить уже свои локи, ловя момент (трихаха).
SVN как раз логически совершенен, а главное - ПОНЯТЕН. Для централизованных команд это самое то.
Git это бл$$$ п$$$ц, там всё устроено чудовищно сложно, для одной и той же операции миллион команд, которые ее выполняют, куча промежуточных состояний до попадания кода в репо, vendor branch это адский ад. Когда немного попривыкнешь, многие вещи начинают казаться как будто нормальными, но ЭТО БЛ$$$ НЕ ТАК.
Git это бл$$$ п$$$ц, там всё устроено чудовищно сложно, для одной и той же операции миллион команд, которые ее выполняют, куча промежуточных состояний до попадания кода в репо, vendor branch это адский ад. Когда немного попривыкнешь, многие вещи начинают казаться как будто нормальными, но ЭТО БЛ$$$ НЕ ТАК.
Вообще, я тут так разгорячился, потому что поначалу гит для меня как раз и казался такой адски чудовищно сложной штукой. Так было пару лет, пока мне это все не осточертело, и я не осилил прочитать, как оно устроено внутри, чтобы наконец начать понимать, чего он мне там пытается объяснить. Как один из показателей, если вы с трудом понимаете, что написано например тут, то это не гит плохой, а вы не впиливаете, чо эта ваще такое тут происходит, потому что матчасть не знаете.
И по факту, за счет отсутствия костылей типа svn:mergeinfo, partial checkout'ов, и прочих наворотов, ломающих стройную картину, гит даже в чем-то для меня теперь проще (точнее предсказуемей). А все это множество его команд - мнимое, и в основном там просто шорткаты для наиболее частых действий, а базовых операций там раз-два и обчелся. И в свн я уже никогда не вернусь по собственному желанию. Но я, конечно, не настаиваю, хотите - живите как жили, с свном.
И по факту, за счет отсутствия костылей типа svn:mergeinfo, partial checkout'ов, и прочих наворотов, ломающих стройную картину, гит даже в чем-то для меня теперь проще (точнее предсказуемей). А все это множество его команд - мнимое, и в основном там просто шорткаты для наиболее частых действий, а базовых операций там раз-два и обчелся. И в свн я уже никогда не вернусь по собственному желанию. Но я, конечно, не настаиваю, хотите - живите как жили, с свном.
>> То есть, чтобы "система управления версиями" не теряла коммиты,
>> её надо как-то специально подстраивать. А патчить её не надо?
> Как вариант, еще достаточно иметь мозг и читать что тебе пишут.
> И если мозга нет или не умеешь читать - то тогда уже да,
> придется специально ее настроить.
> Можно еще, конечно, проповедовать всем палочки для еды
> и заставлять поваров все мелко рубить, аргументируя это тем,
> что острые ножи чересчур опасны, как это делаешь ты.
> При этом я бы не удивлялся, если некоторые люди будут тебя,
> ммм, вежливо сторониться.
Ты правда считаешь, что вот это:
как-то осмысленно для разработчика, который пришёл разрабатывать
встроенную систему, а не собственно гит? Конечно, это объясняет,
почему можно перезаписать историю и сломать то, что туда перед
этим положили другие сотрудники, но даже найти условия, когда
это не просто "update remote refs while sending objects necessary,"
а строго пополнение удалённого репозитория твоими новыми изменениями,
очень непросто.
Для сравнения, другие системы почему-то не прикидываются
"острыми ножами" там, где это не нужно:
Что именно и где должен прочитать новый разработчик про гит,
чтобы заставить его делать не "update remote refs while sending
objects necessary," а "push changes in the local repository
over into a remote repository?"
>> И куда он указывает, если вендор прислал тебе архивчик?
>> Что с ним происходит, когда ты клонируешь репозиторий?
>> Вот-вот.
> Что вот-вот? В каком-нибудь свне с этим как-то проще внезапно стало?
А что, когда-то было сложно? Ветка располагается в том же месте
и ты не теряешь её, если склонируешь этот репозиторий к себе
(например, svnsync-ом).
> Я помню, в свн буке раньше прилагался для этих целей непонятно
> кем поддерживаемый перл скрипт, который импортировывал такие
> архивчики с попыткой найти и захендлить перемещения файлов.
> Через пару часов обезьяней работы у тебя, возможно, что-то
> получалось.
А гит делает это всегда, даже тогда, когда не нужно, из-за чего
нельзя просто так склеить ветки, где вносились изменения
в удалённые тобой файлы.
>> Линух --- большой проект!
> С 15М LoC и 30 годами истории?
Может, ещё и 50 лет ему запишем?
Сколько этой истории в репозитории-то?
И каким способом ты получил историю до 2.6.12?
> Ну да, я думаю, что побольше большинства существующих,
> где-то в p99.999 примерно, я думаю. У тебя какие-то другие оценки?
Да, у меня совсем другие оценки, и линух, с его _неполными_
десятью годами истории --- проект средней величины,
а никак уж не большой.
> Ты о каком недостатке сейчас? Об отсутствии локов?
Ты читаешь то, что тебе пишут?
Ни одна другая распределённая система управления версиями
не является настолько невменяемой ни в смысле существования
невалидных состояний рабочей копии, ни в смысле потери коммитов,
ни в смысле набора команд, ни в смысле документации.
---
A40: Так завещел великий и мудрый LT и по другому называть некошерно.
>> её надо как-то специально подстраивать. А патчить её не надо?
> Как вариант, еще достаточно иметь мозг и читать что тебе пишут.
> И если мозга нет или не умеешь читать - то тогда уже да,
> придется специально ее настроить.
> Можно еще, конечно, проповедовать всем палочки для еды
> и заставлять поваров все мелко рубить, аргументируя это тем,
> что острые ножи чересчур опасны, как это делаешь ты.
> При этом я бы не удивлялся, если некоторые люди будут тебя,
> ммм, вежливо сторониться.
Ты правда считаешь, что вот это:
Updates remote refs using local refs, while sending objects necessary
to complete the given refs.
как-то осмысленно для разработчика, который пришёл разрабатывать
встроенную систему, а не собственно гит? Конечно, это объясняет,
почему можно перезаписать историю и сломать то, что туда перед
этим положили другие сотрудники, но даже найти условия, когда
это не просто "update remote refs while sending objects necessary,"
а строго пополнение удалённого репозитория твоими новыми изменениями,
очень непросто.
Для сравнения, другие системы почему-то не прикидываются
"острыми ножами" там, где это не нужно:
Push changes in the local repository over into a remote repository.
Use the "-R REPO" or "--repository REPO" command-line options
to specify an alternative repository file.
See clone usage for possible URL formats.
If the URL is not specified, then the URL from the most recent
clone, push, pull, remote-url, or sync command is used.
The URL specified normally becomes the new "remote-url" used for
subsequent push, pull, and sync operations. However, the "--once"
command-line option makes the URL a one-time-use URL that is not
saved.
Use the --private option to push private branches to the
remote repository.
Push changesets from the local repository to the specified destination.
This operation is symmetrical to pull: it is identical to a pull in the
destination repository from the current one.
By default, push will not allow creation of new heads at the destination,
since multiple heads would make it unclear which head to use. In this
situation, it is recommended to pull and merge before pushing.
Use --new-branch if you want to allow push to create a new named branch
that is not present at the destination. This allows you to only create a
new branch without forcing other changes.
Note:
Extra care should be taken with the -f/--force option, which will push
all new heads on all branches, an action which will almost always cause
confusion for collaborators.
If -r/--rev is used, the specified revision and all its ancestors will be
pushed to the remote repository.
If -B/--bookmark is used, the specified bookmarked revision, its
ancestors, and the bookmark will be pushed to the remote repository.
Что именно и где должен прочитать новый разработчик про гит,
чтобы заставить его делать не "update remote refs while sending
objects necessary," а "push changes in the local repository
over into a remote repository?"
>> И куда он указывает, если вендор прислал тебе архивчик?
>> Что с ним происходит, когда ты клонируешь репозиторий?
>> Вот-вот.
> Что вот-вот? В каком-нибудь свне с этим как-то проще внезапно стало?
А что, когда-то было сложно? Ветка располагается в том же месте
и ты не теряешь её, если склонируешь этот репозиторий к себе
(например, svnsync-ом).
> Я помню, в свн буке раньше прилагался для этих целей непонятно
> кем поддерживаемый перл скрипт, который импортировывал такие
> архивчики с попыткой найти и захендлить перемещения файлов.
> Через пару часов обезьяней работы у тебя, возможно, что-то
> получалось.
А гит делает это всегда, даже тогда, когда не нужно, из-за чего
нельзя просто так склеить ветки, где вносились изменения
в удалённые тобой файлы.
>> Линух --- большой проект!
> С 15М LoC и 30 годами истории?
Может, ещё и 50 лет ему запишем?
Сколько этой истории в репозитории-то?
И каким способом ты получил историю до 2.6.12?
> Ну да, я думаю, что побольше большинства существующих,
> где-то в p99.999 примерно, я думаю. У тебя какие-то другие оценки?
Да, у меня совсем другие оценки, и линух, с его _неполными_
десятью годами истории --- проект средней величины,
а никак уж не большой.
> Ты о каком недостатке сейчас? Об отсутствии локов?
Ты читаешь то, что тебе пишут?
Ни одна другая распределённая система управления версиями
не является настолько невменяемой ни в смысле существования
невалидных состояний рабочей копии, ни в смысле потери коммитов,
ни в смысле набора команд, ни в смысле документации.
---
A40: Так завещел великий и мудрый LT и по другому называть некошерно.
Как один из показателей, если вы с трудом понимаете, что написано например тут, то это не гит плохой, а вы не впиливаете, чо эта ваще такое тут происходит, потому что матчасть не знаете.Нет, это именно Git плохой, "понимание гит" это именно привыкание к его кривизне, о чем я написал. SVN построен на простой, понятной ЕДИНОЙ адресации по URL, единой нумерации ревизии, простом понятии транзакций. У Git же число концепций овердохуя выше, причем сложность явно избыточная для среднего размера проектов.
У Git же число концепций овердохуя выше, причем сложность явно избыточная для среднего размера проектов.Ага, а самый лучший пользовательский интерфейс — один magic pushbutton на всё.
> Ты правда считаешь, что вот это
Во-первых, для меня это понятно. Во-вторых, ты выдрал одно предложение из контекста, тогда как в остальных примерах отцитировал целые абзацы. В-третьих, как раз у гита дано четкое определение, что есть push, когда в других мануалах по сути просто тавтология "пуш это пуш". В-четвертых, острость ножа не в процитированном тобой куске, а в флажке --force, и там везде об этом написано.
> А что, когда-то было сложно? Ветка располагается в том же месте
> и ты не теряешь её, если склонируешь этот репозиторий к себет
> (например, svnsync-ом).
Хватит прыгать с одного на другое. То ты говоришь об импорте архивчиков в случае гита, а в случае свна вдруг начинаешь это сравнивать с импортом из одной свн-репы в другую (бугагашечки).
Что у тебя в случае "я пуллю из одного гита в другой гит" что-то вдруг теряется и располагается не в тех местах я пока не понимаю.
> А гит делает это всегда, даже тогда, когда не нужно, из-за чего
> нельзя просто так склеить ветки, где вносились изменения
> в удалённые тобой файлы.
Как правило, можно. В корнер-кейсе это можно сделать прочитав ман к git-merge. Для ленивых можно поискать слово rename в нем же.
> Да, у меня совсем другие оценки, и линух, с его _неполными_
> десятью годами истории --- проект средней величины,
> а никак уж не большой.
Приведи свои оценки, я с интересном послушаю.
Если ты говоришь о полуторагиговых репах, что на ~порядок больше линукса, то значит ли это, что стоит рассчитывать на рассказ о сотнях различных проектов с ~100 летней историей и\или ~ >150М строк кода, которые тебе приходится ежедневно мучительно клонить?
> Ты читаешь то, что тебе пишут?
Очень внимательно читаю. И пока вижу только "я ленив, я не умею и не хочу читать мануал, зато у меня есть привычка нарезать продукты с закрытыми глазами и я горжусь ею, бла-бла-бла".
Во-первых, для меня это понятно. Во-вторых, ты выдрал одно предложение из контекста, тогда как в остальных примерах отцитировал целые абзацы. В-третьих, как раз у гита дано четкое определение, что есть push, когда в других мануалах по сути просто тавтология "пуш это пуш". В-четвертых, острость ножа не в процитированном тобой куске, а в флажке --force, и там везде об этом написано.
> А что, когда-то было сложно? Ветка располагается в том же месте
> и ты не теряешь её, если склонируешь этот репозиторий к себет
> (например, svnsync-ом).
Хватит прыгать с одного на другое. То ты говоришь об импорте архивчиков в случае гита, а в случае свна вдруг начинаешь это сравнивать с импортом из одной свн-репы в другую (бугагашечки).
Что у тебя в случае "я пуллю из одного гита в другой гит" что-то вдруг теряется и располагается не в тех местах я пока не понимаю.
> А гит делает это всегда, даже тогда, когда не нужно, из-за чего
> нельзя просто так склеить ветки, где вносились изменения
> в удалённые тобой файлы.
Как правило, можно. В корнер-кейсе это можно сделать прочитав ман к git-merge. Для ленивых можно поискать слово rename в нем же.
> Да, у меня совсем другие оценки, и линух, с его _неполными_
> десятью годами истории --- проект средней величины,
> а никак уж не большой.
Приведи свои оценки, я с интересном послушаю.
Если ты говоришь о полуторагиговых репах, что на ~порядок больше линукса, то значит ли это, что стоит рассчитывать на рассказ о сотнях различных проектов с ~100 летней историей и\или ~ >150М строк кода, которые тебе приходится ежедневно мучительно клонить?
> Ты читаешь то, что тебе пишут?
Очень внимательно читаю. И пока вижу только "я ленив, я не умею и не хочу читать мануал, зато у меня есть привычка нарезать продукты с закрытыми глазами и я горжусь ею, бла-бла-бла".
Нет, это именно Git плохой, "понимание гит" это именно привыкание к его кривизне, о чем я написал. SVN построен на простой, понятной ЕДИНОЙ адресации по URL, единой нумерации ревизии, простом понятии транзакций. У Git же число концепций овердохуя выше, причем сложность явно избыточная для среднего размера проектов.Позиция "я этого не понимаю, поэтому оно плохое" мне вполне понятна. Почему она мне не очень близка, думаю, пояснять не надо.
В гите все тоже строится вокруг объектов и их идентификаторах-хешах контента объекта. Есть три типа объектов - блоб, дерево (которое композиция блобов, а точнее их хешей и коммит (который хеш дерева плюс хеш парентов плюс авторинг). И абсолютно все строится вокруг этого.
Бранчи, индексы, рефлоги, ресеты, пуши, мерджи, ребейзы, коммиты, фетчи, пуллы, итд етц - все выражается в этих трех типах и несложных операциях над ними.
На все потенциально деструктивные действия надо явно указать флажок, типа --force или --hard.
Если ты завис в непонятном стейте, типа посреди ребейза, то git status расскажет тебе, что происходит и даже подскажет команды, которые делают наиболее частые хотелки в твоей ситуации.
Даже когда ты делаешь чекаут определенного коммита, на что выше жаловался кохтпа, гит тут же предупредит, что ты в 'detached HEAD state', чем это чревато, и как легко не потерять свои изменения (см ниже). Но людям, которым недосуг читать, зато очень хочется поныть, это все, конечно, совершенно никак не помогает.
$ git checkout 001955f
Note: checking out '001955f'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
>> Ты правда считаешь, что вот это
> Во-первых, для меня это понятно.
Сколько времени ты потратил на то, чтобы оно тебе стало понятно?
> Во-вторых, ты выдрал одно предложение из контекста,
> тогда как в остальных примерах отцитировал целые абзацы.
Я могу процитировать и полностью:
Как легко увидеть, три абзаца, которые я опустил, никакого
особого знания не добавляют.
> В-третьих, как раз у гита дано четкое определение, что есть push,
> когда в других мануалах по сути просто тавтология "пуш это пуш".
Твоё "чёткое определение" вводит новое понятие "refs" и использует
слово "update," имеющее немного несловарное значение в ИТ, тогда как
в других системах используется словарное значение слова "push."
> В-четвертых, острость ножа не в процитированном тобой куске,
> а в флажке --force, и там везде об этом написано.
Ты правда считаешь, что документацию к "--force" понять просто?
Почему описание аналогичной операции в "меркуриале" значительно проще?
>> А что, когда-то было сложно? Ветка располагается в том же месте
>> и ты не теряешь её, если склонируешь этот репозиторий к себет
>> (например, svnsync-ом).
> Хватит прыгать с одного на другое. То ты говоришь об импорте
> архивчиков в случае гита, а в случае свна вдруг начинаешь
> это сравнивать с импортом из одной свн-репы в другую (бугагашечки).
> Что у тебя в случае "я пуллю из одного гита в другой гит"
> что-то вдруг теряется и располагается не в тех местах я пока
> не понимаю.
Алё, я не прыгаю с одного на другое, а вот о том, что ты пишешь,
мне приходится уже догадываться.
Когда ты делаешь "clone", у тебя все твои удалённые репозитории
теряются, поэтому, если ты реализуешь вендорную ветку через
дополнительный внешний репозиторий, она у тебя исчезает.
Это очень прикольно, если учесть, что распределённая система
должна давать возможность работы при полном отключении от сети.
Внезапно, оказывается, что поверх гита надо писать примочку,
которая будет клонировать два репозитория и перенастраивать их
взаимосвязи. Такой аналог CVS поверх RCS.
>> А гит делает это всегда, даже тогда, когда не нужно, из-за чего
>> нельзя просто так склеить ветки, где вносились изменения
>> в удалённые тобой файлы.
> Как правило, можно. В корнер-кейсе это можно сделать прочитав ман к git-merge.
Нельзя.
Здесь уже очевидно, что ты теоретизируешь.
>> Да, у меня совсем другие оценки, и линух, с его _неполными_
>> десятью годами истории --- проект средней величины,
>> а никак уж не большой.
> Приведи свои оценки, я с интересном послушаю.
> Если ты говоришь о полуторагиговых репах, что на ~порядок
> больше линукса, то значит ли это, что стоит рассчитывать на
> рассказ о сотнях различных проектов с ~100 летней историей
> и\или ~ >150М строк кода, которые тебе приходится ежедневно
> мучительно клонить?
Вот именно. У некоторых линукс является не самой большой частью
рабочего кода, а десять лет истории с большим количеством файлов
уже дают тебе порядок.
>> Ты читаешь то, что тебе пишут?
> Очень внимательно читаю. И пока вижу только "я ленив, я не
> умею и не хочу читать мануал, зато у меня есть привычка
> нарезать продукты с закрытыми глазами и я горжусь ею,
> бла-бла-бла".
Пока что видно, что ты читаешь только урывками, зато гонору
у тебя от того, что ты выучил единственную распределённую
систему из многих и насобачился работать с ней каким-то
таинственным методом, не описанным в официальной документации,
выше крыши.
Это круто, конечно, что ты потратил время на то, чтобы выучить
свой собственный язык, где "updates remote refs using local refs,
while sending objects necessary to complete the given refs"
имеет смысл и не требует дальнейших пояснений, и научился
тщательно обходить густо рассыпанные грабли, но в реальной
жизни получается так, что есть люди, которым VCS нужна не как
самоцель.
---
Q11: *ix это че?
A11: Это кодовое название проекта следующего (после K&R) поколения
под рабочим названием Хрюних.
> Во-первых, для меня это понятно.
Сколько времени ты потратил на то, чтобы оно тебе стало понятно?
> Во-вторых, ты выдрал одно предложение из контекста,
> тогда как в остальных примерах отцитировал целые абзацы.
Я могу процитировать и полностью:
Updates remote refs using local refs, while sending objects necessary
to complete the given refs.
You can make interesting things happen to a repository every time you
push into it, by setting up hooks there. See documentation for git-
receive-pack(1).
When the command line does not specify where to push with the
<repository> argument, branch.*.remote configuration for the current
branch is consulted to determine where to push. If the configuration is
missing, it defaults to origin.
When the command line does not specify what to push with <refspec>...
arguments or --all, --mirror, --tags options, the command finds the
default <refspec> by consulting remote.*.push configuration, and if it
is not found, honors push.default configuration to decide what to push
(See git-config(1) for the meaning of push.default).
Как легко увидеть, три абзаца, которые я опустил, никакого
особого знания не добавляют.
> В-третьих, как раз у гита дано четкое определение, что есть push,
> когда в других мануалах по сути просто тавтология "пуш это пуш".
Твоё "чёткое определение" вводит новое понятие "refs" и использует
слово "update," имеющее немного несловарное значение в ИТ, тогда как
в других системах используется словарное значение слова "push."
> В-четвертых, острость ножа не в процитированном тобой куске,
> а в флажке --force, и там везде об этом написано.
Ты правда считаешь, что документацию к "--force" понять просто?
Почему описание аналогичной операции в "меркуриале" значительно проще?
>> А что, когда-то было сложно? Ветка располагается в том же месте
>> и ты не теряешь её, если склонируешь этот репозиторий к себет
>> (например, svnsync-ом).
> Хватит прыгать с одного на другое. То ты говоришь об импорте
> архивчиков в случае гита, а в случае свна вдруг начинаешь
> это сравнивать с импортом из одной свн-репы в другую (бугагашечки).
> Что у тебя в случае "я пуллю из одного гита в другой гит"
> что-то вдруг теряется и располагается не в тех местах я пока
> не понимаю.
Алё, я не прыгаю с одного на другое, а вот о том, что ты пишешь,
мне приходится уже догадываться.
Когда ты делаешь "clone", у тебя все твои удалённые репозитории
теряются, поэтому, если ты реализуешь вендорную ветку через
дополнительный внешний репозиторий, она у тебя исчезает.
Это очень прикольно, если учесть, что распределённая система
должна давать возможность работы при полном отключении от сети.
Внезапно, оказывается, что поверх гита надо писать примочку,
которая будет клонировать два репозитория и перенастраивать их
взаимосвязи. Такой аналог CVS поверх RCS.
>> А гит делает это всегда, даже тогда, когда не нужно, из-за чего
>> нельзя просто так склеить ветки, где вносились изменения
>> в удалённые тобой файлы.
> Как правило, можно. В корнер-кейсе это можно сделать прочитав ман к git-merge.
Нельзя.
Здесь уже очевидно, что ты теоретизируешь.
>> Да, у меня совсем другие оценки, и линух, с его _неполными_
>> десятью годами истории --- проект средней величины,
>> а никак уж не большой.
> Приведи свои оценки, я с интересном послушаю.
> Если ты говоришь о полуторагиговых репах, что на ~порядок
> больше линукса, то значит ли это, что стоит рассчитывать на
> рассказ о сотнях различных проектов с ~100 летней историей
> и\или ~ >150М строк кода, которые тебе приходится ежедневно
> мучительно клонить?
Вот именно. У некоторых линукс является не самой большой частью
рабочего кода, а десять лет истории с большим количеством файлов
уже дают тебе порядок.
>> Ты читаешь то, что тебе пишут?
> Очень внимательно читаю. И пока вижу только "я ленив, я не
> умею и не хочу читать мануал, зато у меня есть привычка
> нарезать продукты с закрытыми глазами и я горжусь ею,
> бла-бла-бла".
Пока что видно, что ты читаешь только урывками, зато гонору
у тебя от того, что ты выучил единственную распределённую
систему из многих и насобачился работать с ней каким-то
таинственным методом, не описанным в официальной документации,
выше крыши.
Это круто, конечно, что ты потратил время на то, чтобы выучить
свой собственный язык, где "updates remote refs using local refs,
while sending objects necessary to complete the given refs"
имеет смысл и не требует дальнейших пояснений, и научился
тщательно обходить густо рассыпанные грабли, но в реальной
жизни получается так, что есть люди, которым VCS нужна не как
самоцель.
---
Q11: *ix это че?
A11: Это кодовое название проекта следующего (после K&R) поколения
под рабочим названием Хрюних.
> тогда как в других системах используется словарное значение слова "push."
Если пуш у тебя имеет словарное значение, на которое ты полагаешься, то зачем тебе вообще какая-либо документация к git-push, если само название уже включает нужное значение?
Какое "особое значение" тебе добавляет документация вида "пуш это пуш"?
Из контекста, кстати, выкинуты куски как раз с этим самым словом.
> Когда ты делаешь "clone", у тебя все твои удалённые репозитории
> теряются, поэтому, если ты реализуешь вендорную ветку через
> дополнительный внешний репозиторий, она у тебя исчезает.
В следующий раз попробуй сначала прочитать man git-remote и man git-fetch.
> Нельзя. Здесь уже очевидно, что ты теоретизируешь.
Конечно, так как ты не приводишь полных примеров, то за тобой постоянно приходится домысливать. Я, повторяю, утверждаю, что можно, и даже не поленюсь скопировать:
Жду конкретного примера, когда это все не работает в гит, но отлично работает в <your_choice_vcs>.
> Вот именно. У некоторых линукс является не самой большой частью
> рабочего кода, а десять лет истории с большим количеством файлов
> уже дают тебе порядок.
Что "вот именно"? Я на конкретный вопрос получил в ответ абстрактную фразу с нулем добавочного смысла. Ну и?
> Пока что видно, что ты читаешь только урывками, зато гонору
> у тебя от того, что ты выучил единственную распределённую
> систему из многих и насобачился работать с ней каким-то
> таинственным методом, не описанным в официальной документации,
> выше крыши.
Тебе, очевидно, нравится генерировать такие фразы с нулем конкретики, которые лишь переливают из пустого в порожнее. Я просто удовлетворяю твою потребность в этом, и реагирую на них в твоем же стиле:
Пока что видно, что ты отвечаешь урывками, приводя минимум конкретики и максимум неаргументированных абстрактных фраз вида "у меня в гите что-то не работает!", имеешь банальную склонность судить о том, в чем не дал себе труда разобраться, зато гонору у тебя от намеков на огромные масштабы постоянного клонирования неведомого что-то в неведомое куда-то выше крыши.
И так далее и тому подобное. Бла-бла-бла.
Если пуш у тебя имеет словарное значение, на которое ты полагаешься, то зачем тебе вообще какая-либо документация к git-push, если само название уже включает нужное значение?
Какое "особое значение" тебе добавляет документация вида "пуш это пуш"?
Из контекста, кстати, выкинуты куски как раз с этим самым словом.
> Когда ты делаешь "clone", у тебя все твои удалённые репозитории
> теряются, поэтому, если ты реализуешь вендорную ветку через
> дополнительный внешний репозиторий, она у тебя исчезает.
В следующий раз попробуй сначала прочитать man git-remote и man git-fetch.
> Нельзя. Здесь уже очевидно, что ты теоретизируешь.
Конечно, так как ты не приводишь полных примеров, то за тобой постоянно приходится домысливать. Я, повторяю, утверждаю, что можно, и даже не поленюсь скопировать:
$ man git-mergeТы волен выбрать себе по душе другой merge strategy или другой rename-threshold.
...
MERGE STRATEGIES
...
recursive
This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge,
it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in
fewer merge conflicts without causing mis-merges by tests done on actual merge commits taken from Linux 2.6 kernel development history.
Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch.
...
rename-threshold=<n>
Controls the similarity threshold used for rename detection. See also git-diff(1) -M.
...
Жду конкретного примера, когда это все не работает в гит, но отлично работает в <your_choice_vcs>.
> Вот именно. У некоторых линукс является не самой большой частью
> рабочего кода, а десять лет истории с большим количеством файлов
> уже дают тебе порядок.
Что "вот именно"? Я на конкретный вопрос получил в ответ абстрактную фразу с нулем добавочного смысла. Ну и?
> Пока что видно, что ты читаешь только урывками, зато гонору
> у тебя от того, что ты выучил единственную распределённую
> систему из многих и насобачился работать с ней каким-то
> таинственным методом, не описанным в официальной документации,
> выше крыши.
Тебе, очевидно, нравится генерировать такие фразы с нулем конкретики, которые лишь переливают из пустого в порожнее. Я просто удовлетворяю твою потребность в этом, и реагирую на них в твоем же стиле:
Пока что видно, что ты отвечаешь урывками, приводя минимум конкретики и максимум неаргументированных абстрактных фраз вида "у меня в гите что-то не работает!", имеешь банальную склонность судить о том, в чем не дал себе труда разобраться, зато гонору у тебя от намеков на огромные масштабы постоянного клонирования неведомого что-то в неведомое куда-то выше крыши.
И так далее и тому подобное. Бла-бла-бла.
Позиция "я этого не понимаю, поэтому оно плохое" мне вполне понятна. Почему она мне не очень близка, думаю, пояснять не надо.То, что я написал, ты явно не прочел. У меня нет проблем с пониманием Git. Я понимаю, что разработчики пытались честно отработать идею, но она выросла, как снежный ком, и погребла под собой всё, в том числе саму себя. По существу есть что сказать? Попробуй для начала придумать ситуацию, когда нужно выбросить SVN и использовать Git.
>> тогда как в других системах используется словарное значение слова "push."
> Если пуш у тебя имеет словарное значение, на которое ты полагаешься,
> то зачем тебе вообще какая-либо документация к git-push,
> если само название уже включает нужное значение?
Затем, что "git push" внезапно отличается от "hg push" и "fossil push"
тем, что позволяет _удалять_ данные из репозитория.
>> Когда ты делаешь "clone", у тебя все твои удалённые репозитории
>> теряются, поэтому, если ты реализуешь вендорную ветку через
>> дополнительный внешний репозиторий, она у тебя исчезает.
> В следующий раз попробуй сначала прочитать man git-remote
> и man git-fetch.
Каким образом оно относится?
"git fetch" создаёт новый репозиторий или рабочую копию?
>> Нельзя. Здесь уже очевидно, что ты теоретизируешь.
> Конечно, так как ты не приводишь полных примеров,
> то за тобой постоянно приходится домысливать.
> Я, повторяю, утверждаю, что можно, и даже не поленюсь скопировать:
>> Additionally this can detect and handle merges involving renames.
>> This is the default merge strategy when pulling or merging one branch.
>> ...
>> rename-threshold=<n>
>> Controls the similarity threshold used for rename detection. See also git-diff(1) -M.
>> ...
> Ты волен выбрать себе по душе другой merge strategy
> или другой rename-threshold.
Ну, так, покажи, какую стратегию надо выбрать, чтобы гит
склеивал только файлы с одинаковыми именами, а не пытался
что-то там угадывать.
> Жду конкретного примера, когда это все не работает в гит,
> но отлично работает в <your_choice_vcs>.
Конкретного примера не будет, так как это тебе не линукс.
>> Пока что видно, что ты читаешь только урывками, зато гонору
>> у тебя от того, что ты выучил единственную распределённую
>> систему из многих и насобачился работать с ней каким-то
>> таинственным методом, не описанным в официальной документации,
>> выше крыши.
> Тебе, очевидно, нравится генерировать такие фразы с нулем конкретики
Что именно из объяснённого выше тебе не понятно?
Ну, и да. Знаний других систем никаких, а гонор так и прёт.
---
A40: Так завещел великий и мудрый LT и по другому называть некошерно.
> Если пуш у тебя имеет словарное значение, на которое ты полагаешься,
> то зачем тебе вообще какая-либо документация к git-push,
> если само название уже включает нужное значение?
Затем, что "git push" внезапно отличается от "hg push" и "fossil push"
тем, что позволяет _удалять_ данные из репозитория.
>> Когда ты делаешь "clone", у тебя все твои удалённые репозитории
>> теряются, поэтому, если ты реализуешь вендорную ветку через
>> дополнительный внешний репозиторий, она у тебя исчезает.
> В следующий раз попробуй сначала прочитать man git-remote
> и man git-fetch.
Каким образом оно относится?
"git fetch" создаёт новый репозиторий или рабочую копию?
>> Нельзя. Здесь уже очевидно, что ты теоретизируешь.
> Конечно, так как ты не приводишь полных примеров,
> то за тобой постоянно приходится домысливать.
> Я, повторяю, утверждаю, что можно, и даже не поленюсь скопировать:
>> Additionally this can detect and handle merges involving renames.
>> This is the default merge strategy when pulling or merging one branch.
>> ...
>> rename-threshold=<n>
>> Controls the similarity threshold used for rename detection. See also git-diff(1) -M.
>> ...
> Ты волен выбрать себе по душе другой merge strategy
> или другой rename-threshold.
Ну, так, покажи, какую стратегию надо выбрать, чтобы гит
склеивал только файлы с одинаковыми именами, а не пытался
что-то там угадывать.
> Жду конкретного примера, когда это все не работает в гит,
> но отлично работает в <your_choice_vcs>.
Конкретного примера не будет, так как это тебе не линукс.
>> Пока что видно, что ты читаешь только урывками, зато гонору
>> у тебя от того, что ты выучил единственную распределённую
>> систему из многих и насобачился работать с ней каким-то
>> таинственным методом, не описанным в официальной документации,
>> выше крыши.
> Тебе, очевидно, нравится генерировать такие фразы с нулем конкретики
Что именно из объяснённого выше тебе не понятно?
Ну, и да. Знаний других систем никаких, а гонор так и прёт.
---
A40: Так завещел великий и мудрый LT и по другому называть некошерно.
> То, что я написал, ты явно не прочел. У меня нет проблем с пониманием Git.
Давай вместе читать твои посты. Ты даешь свою оценку, сравнивая гит с свн:
> SVN как раз логически совершенен, а главное - ПОНЯТЕН
vs
> Git это бл$$$ п$$$ц, там всё устроено чудовищно сложно
При этом проблем с пониманием у тебя все-таки нету, но тогда откуда "бл пц все сложно"?
> Попробуй для начала придумать ситуацию, когда нужно выбросить SVN и использовать Git.
Приведенный мной выше ручной мердж svn:mergeinfo тебе чем-то не подходит?
Давай вместе читать твои посты. Ты даешь свою оценку, сравнивая гит с свн:
> SVN как раз логически совершенен, а главное - ПОНЯТЕН
vs
> Git это бл$$$ п$$$ц, там всё устроено чудовищно сложно
При этом проблем с пониманием у тебя все-таки нету, но тогда откуда "бл пц все сложно"?
> Попробуй для начала придумать ситуацию, когда нужно выбросить SVN и использовать Git.
Приведенный мной выше ручной мердж svn:mergeinfo тебе чем-то не подходит?
> Затем, что "git push" внезапно отличается от "hg push" и "fossil push"
> тем, что позволяет _удалять_ данные из репозитория.
Позволяет и не позволять, вообще-то.
receive.denyDeletes
If set to true, git-receive-pack will deny a ref update that deletes the ref. Use this to
prevent such a ref deletion via a push.
> тем, что позволяет _удалять_ данные из репозитория.
Позволяет и не позволять, вообще-то.
receive.denyDeletes
If set to true, git-receive-pack will deny a ref update that deletes the ref. Use this to
prevent such a ref deletion via a push.
ох ебать вы тут простыней настрочили! 
бл
Не говори. Тут иногда обычные конфликты в svn смерджить нормально не выходит, а они целую науку расписывают
Не говори. Тут иногда обычные конфликты в svn смерджить нормально не выходит, а они целую науку расписывают
> Тут иногда обычные конфликты в svn смерджить нормально не выходит
Ты не понял. Гит, он всё сделает. Тебе надо срочно перейти на гит.
---
Q5: а нафига A4?
A5: чтоб сосать.
Ты не понял. Гит, он всё сделает. Тебе надо срочно перейти на гит.
---
Q5: а нафига A4?
A5: чтоб сосать.
Гит, он всё сделаетАга, особенно отследит изменения в бинарниках, созданных неизвестно чем
Тебе надо срочно перейти на гитЭххх. Если б я был один
Твоё "чёткое определение" вводит новое понятие "refs" и используетРеф - это файл в папке .git/refs/head. Название файла совпадает с названием ветки, содержимое файла - это хэш коммита. При пуше эти файлы копируются в папку .git на сервере. Аналогично, объекты - файлы в папке .git/objects.
слово "update," имеющее немного несловарное значение в ИТ, тогда как
в других системах используется словарное значение слова "push."
Как видишь, все просто и юникс-вей. Многие операции гита можно делать без использования git cli, а просто текстовым редактором - большое количество данных лежит в .git в виде плейнтекста.
У Git же число концепций овердохуя выше
Это неправда. Все бинарные структуры гита описываются подробно на двух страницах. Смотри, например, тут
Все остальное - плейнтекст, можешь сам посмотреть как устроена папка .git
CLI можно осваивать по мере надобности
> Эххх. Если б я был один
git-svn не?
git-svn не?
Оставить комментарий
NataNata
Осваиваю сейчас инфраструктуру для явы по автоматизации сборки проектов, тестирования, непрерывной интеграции. Все будет прогаться несколькими людьми, прога будет bigdate-ной и распределенной.Подскажите плз:
1) существуют ли в природе готовые линуксные дистрибутивы, на которых уже настроены, подняты всевозможные ide, сервера, чтобы сразу работать? я все настроил ручками, могу написать и скрипты для разворачивания этого добра на новых машинах, но, наверное, все уже написано
ну или не дистрибутивы, а скрипты-разворачиватели
2) пусть я сделал новый билд и хочу его потестить на кластере из вирт машин. Для этого надо их развернуть, настроить, поставить туда явовский проект со всем чем надо и пустить. Беглый поиск навел на vagrant + Docker. Я то, что надо, нашел?
3) (холиворное) intellij idea (eclipse мне неудобен gradle, jenkins, svn (хочу git, но другие чуваки в команде упираются и хотят svn, не знаю, упираться ли рогами мне findbugs. Все годится? Что еще забыто?