Подготовлен (https://lkml.org/lkml/2018/1/18/18) выпуск распределенной системы управления исходными текстами Git 2.16.0 (http://git-scm.com/). Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. По сравнению с прошлым выпуском в новую версию принято 509 изменений, подготовленных при участии 91 разработчика, из которых 26 впервые приняли своё участие в разработке.Основные изменения (https://github.com/git/git/blob/v2.16.0/Documentation/RelNot...):
- Использование пустой строки в качестве охватывающей все варианты маски пути теперь считается ошибкой. Например, команда git add '' больше не будет работать. Указанная возможность была объявлена устаревшей ещё в 2016 году;
- Скрипты с реализацией хуков отныне будут игнорироваться если для них не выставлен флаг исполняемого файла. По умолчанию при подобном игнорировании будет выводиться предупреждение, которое можно отключить через опцию advice.ignoredHook;
- В "git pull" добавлена обработка опции "--[no-]signoff" и её передача в "git merge";
- Значение опции "--push-option=строка" к "git push" теперь по умолчанию устанавливается в список строк, установленный через переменную push.pushOption;
- В "gitweb" для проверки доступа к директории вместо Perl-оператора "-x" применена pragma "filetest 'access'";- Команда "git stash save" объявлена устаревшей, вместо неё следует использовать "git stash push";
- Обработчик для взаимодействия с MediaWiki переработан для работы с пространствами имён mediawiki и корректной обработки слишком длинных имён страниц (теперь имена обрезаются без потери суффикса ".mw");
- В команде "git for-each-ref" опция "--format=..." расширена возможностью отображения имени внешнего репозитория и его использования на удалённой стороне в 'upstream' и 'push' через параметр "%(push:remotename)";
- Выполнение "git bisect run" без явного указания каких-либо команд теперь приводит к выводу ошибки, вместо обработки всех коммитов как успешно протестированных;
- Представлено новое расширение fsmonitor для взаимодействия со средствами мониторинга состояния ФС, позволяющее ускорить выполнение "git status" и других операций, которым необходимо отслеживать какие из файлов были изменены;- В командах семейства "diff" обеспечено игнорирование различий в указании возврата каретки в конце строки;
- Команда "git add --renormalize ." теперь позиционируется как новый и надёжный способ записи сведений о нормализации символов конца строки и других замен в данных репозитория при помощи функции "convert_to_git()";- В командах "git branch" и "git checkout -b" теперь блокируют попытки создания ветки с именем "HEAD";
- В команде "git branch --list" по умолчанию реализован вывод с использованием постраничного просмотра (pager), когда содержимое не вмещается в терминал. По аналогии с "git tag --list" данное поведение можно контролировать при помощи настройки pager.branch;
- В команды подобные "git grep -W" и "git diff -W" добавлена эвристика для раскрытия строк, похожих на функцию (например "diff.*.xfuncname") для включения в вывод блоков комментариев, идущих непосредственно перед вводимым элементом;
- В "git config --expiry-date gc.reflogexpire" обеспечена обработка параметров времени в виде "2.weeks" по аналогии с обработкой
"1k" в "--int" как 1024;- Имена тегов в "git log --decorate", используемых для аннотирования коммитов, теперь могут быть ограничены подмножеством доступных ref-ссылок, выбранных при помощи опций "--decorate-refs=шаблон" и "--decorate-refs-exclude=шаблон";
- Устранена проблема, приводившая к крахам при выполнении "git grep", если осуществлена сборка с libpcre2;- В "git send-email" добавлена проверка наличия sendmail не только в /usr/lib и /usr/sbin, но и в других путях из списка $PATH;
- В команду "git diff" добавлена опция "--anchored" с реализацией варианта алгоритма "--patience", позволяющего задать уникальную строку, используемую в качестве опорной точки;
- Добавлена настройка rebase.abbreviateCommands, при которой
"git rebase -i" генерирует список todo с указанием односимвольных аббревиатур имён команд;- В команде "git svn" обеспечена очистка символов возврата каретки в сообщениях коммитов по аналогии с поведением Subversion;
- Добавлена поддержка URL https:// для http.proxy при использовании свежих версий libcurl;
- Команда "git merge" теперь проверяет наличие настройки merge.verifySignatures и использует её значение, как если бы в командной строке была указана опция '--verify-signatures'.
- Реализации "git bisect" и "git submodule" переписаны на Си;
- Проведена оптимизация кода для поиска кратчайшего уникального префикса имён объектов.URL: https://lkml.org/lkml/2018/1/18/18
Новость: http://www.opennet.me/opennews/art.shtml?num=47935
Какой мячик есть, таким и играем. Ну ещё есть fossil, на любителя.
> Какой мячик есть, таким и играем. Ну ещё есть fossil, на любителя.это вы красиво щас сформулировали "на любителя". А когда любителей становится хотя бы трое, приходится искать что-то более эффективное.
в принципе, есть еще hg. Который хотя и написан на пихоне со всеми вытекающими, но для решения повседневных задач (более сложных, чем тупoй push) более-менее подходит. Если, конечно, ты можешь вообще ужиться с log-driven history (которая, на мой взгляд, фатальный design flaw - да и не только мой, учитывая неимоверное количество костылей и подпорок, понаписанных чтобы как-то обойти хотя бы часть ее проблем).
Вообще повседневные задачи за рамки pull / checkout / checkout -b / add / commit / push выходить и не должны, если это хоть как-то централизованная разработка, где все тесты, ревью, мержи делаются в соответствущей тулзе.
> Вообще повседневные задачи за рамки pull / checkout / checkout -b / add / commit / push
> выходить и не должныНовая Папка 2309, Новая Папка 2309(копия)...
где-то я это все уже видел.Зачем вам система контроля версий, если никакого контроля у вас и в помине нет?
Контроль версий КОДА - как раз есть. Версии ПРОДУКТА - это к системе управления проектами и CI, где и должны создаваться релизные ветки или теги.
Какие странные представления о контроле версий...
> Какие странные представления о контроле версий...Коллега говорит не про исходники, а про модный ITIL. Промышленное АйТи, понимаете? Манагамент!
Ищите в интернетах "управление релизами"/"release management".
" Процесс «управление релизами», один из стека процессов ITSM, как раз и предлагает решение для формальной приоритизации и группировки запросов пользователей (запросов на изменения, инцидентов) в общие пакеты доставки — «релизы». " --https://habrahabr.ru/post/321664/
rebase -i для наведения порядка в *незапушенных* коммитах тоже бывает полезен.
А что юзабильное?
ртуть
> ртутьпока ты не обнаруживаешь, что два комита назад случайно написал слово $у# в коммит-мессадж.
После чего создал новую ветку (иногда хочется именно настоящих веток, а не ползающих тегов), поэтому даже если у тебя нет клонов и даже с помощью histedit (который это делает, мягко говоря, через анус) ничего изменить нельзя, так и будешь жить дальше с $уем.все эксперименты, все опечатки, все ошибочно засосанные коллекции качественного порно с конями - живут в результате в репо вечно, если только тебе не повезло заметить проблему немедленно - последний коммит всегда можно удалить (поэтому все рассуждения авторов о том что манипулировать историей непорядочно, я склонен считать бесполезной попыткой оправдать уродство дизайна, скопипащеного с понятно-чего, в виду отсутствия своих идей)
Ну и до кучи - нет никакой возможности сосияльных взаимоотсношений между разработчиками - единственный нормально поддерживающий hg сервис принадлежал microsoft, и успешно ей похоронен.
А возможности обзавестись собственным вообще никогда не было.
>нет никакой возможности сосияльных взаимоотсношений между разработчиками
> - единственный нормально поддерживающий hg сервис принадлежал microsoft, и успешно ей
> похоронен.
> А возможности обзавестись собственным вообще никогда не было.Глазам не верю. Такие правильности от Вурдалака. Вы меня не обманываете?!
Вы там ближе, не знаете, может они и "проблемой гитхаба" заинтересуются, команду гробовщиков вышлют??
Впочем, нет. Надо держаться! Атож, сбудется -- никаким фейри не отмоешься---
>случайно написал слово $у# в коммит-мессадж.не хочу спорить о возможности менять историю. мне удобнее, когда ее нельзя менять, но каждый дро4ит-как-хочит.
если нужна какая-то премодерация комитов по своему формату, это опционально решается отдельными тулами по хуками/ci.>единственный нормально поддерживающий hg сервис принадлежал microsoft, и успешно ей похоронен.
а что не так с битбакетом? и там даже бесплатные закрытые репы вести можно, в отличие от гитхаба.
что до веток, то настоящие ветки как раз в меркуриале, имхо. (https://habrahabr.ru/post/123700/)
в гите меня больше всего бесит его оверусложненный интерфейс с кучей избыточных и неочевидных разнородных параметров. возможность помержить больше двух веток за раз я тоже считаю только вредной. потом хрен разберешь по истории что-откуда пришло.
но не хочу разводить холивар, функционально то гит с меркуриалом практически одинаковы.
> не хочу спорить о возможности менять историю. мне удобнее, когда ее нельзя менятьприкол в том, что менять-то можно - но только на шаг назад. Не спохватился вовремя - проехали.
> а что не так с битбакетом?
git enforcing во все дырки, разумеется. Как и у гитлаба (который тоже еще поддерживает, но тоже на от..сь, а в stand-alone версии вообще ничего нет)
> что до веток, то настоящие ветки как раз в меркуриале, имхо. (https://habrahabr.ru/post/123700/)
ну вот, собственно, о том и речь - с гитом все прекрасно, пока для тебя существует только текущее состояние. Как только надо разбираться, что откуда взялось и с какого места начинать возиться с проблемой - опа, ничего неясно, и инструментов нет, отслеживай вручную кто на ком стоял. (и людей, которые могут подсказать, тоже по пальцам одной руки пересчитать можно)
> прикол в том, что менять-то можно - но только на шаг назад. Не спохватился вовремя - проехали.hg rebase не осилил?
>> прикол в том, что менять-то можно - но только на шаг назад. Не спохватился вовремя - проехали.
> hg rebase не осилил?только вот пушнутые комиты не получится ребейзнуть, что имхо логично. а незапушенное можно хоть как поменять.
>только вот пушнутые комиты не получится ребейзнуть, что имхо логично. а незапушенное можно хоть как поменять.не так все страшно. если что-то реально нужно поправить, это можно сделать через force push или strip(на сервере) и push. это далеко не тривиальные операции, но даже это гораздо проще в использовании, чем в git. ну а если в репозиторий часто попадает лажа, может "дело не в бобине"?
> в гите меня больше всего бесит его оверусложненный интерфейсДа, двухколёсный велосипед сложнее трёхколёсного. Не стоит спешить.
> функционально-то гит с меркуриалом практически одинаковы
Нет.
Да. Есть куча примеров того, что не может, и может другой. Но в целом функционал один. Меркуриал умеет больше в целом за счет расширений, гит больше "из коробки".
да я и не спешу - успешно еду с удовольствием на трехколесном, зато без палок в колеса на пустом месте)
все возникающие задачи успешно решаются очевидным образом. за это мне hg и нравится.>нет
можно плз юзкейс - что может гит, и не может hg?
Ок, спрошу, раз остальным лень. И чем именно они неюзабельные?
Можете попробовать fossil-scm.
фоссил уже давно стал сам ископаемым. был у них план какой-то переписать его, прчем чтобы могли экспортироваться нативном репозитории из гита, свн и меркуриала, но что-то все заглохло.
> Можете попробовать fossil-scm.Понюхали. Дефективен на уровне архитектурного решения, в принципе не может считаться DVCS (буква D --- существенна).
В последнее время народ с Фоссила уходит:https://roy.marples.name/blog/goodbye-fossil
Автор кстати после этого рекламирует Phabricator:
такой народ - пусть уходит, и подальше, подальше.> https://roy.marples.name/blog/goodbye-fossil
It's not social.
Па-а-анятен (половина остальных претензий, собственно, тот же мотив на разные лады)фабрикатор, если что - это очередная сосияльная сеточка для околоразработчиков. Нeнужен.
Фабрикатор - это, кроме всего, удобные ревью с навороченной логикой signoff.
Ага, умники. 99% вакансий на разраба требуют GIT, это уже промстандарт. А этим гаврикам не нужно. Ок, удачи вам в поиске хорошей работы.Новая папка 1, Новая папка 2... ваше все.
Я может тебя удивлю, но 90% линуксоидов не ищут работу по вакансиям, их работодатели сами зовут. Вакансии для джунов, а там действительно приходится учить то что популярно, а не то что нравится.
>Вакансии для джунов, а там действительно приходится
> учить то что популярно, а не то что нравится.Спасибо. И кто сказал, что старость не радость. >>>,,,>
> Спасибо. И кто сказал, что старость не радость. >>>,,,>Поттеринг!
>Я может тебя удивлюНа счёт него не знаю, но меня ты точно удивил.
Тем не менее кругом Git, к счастью
Да, куда там! Рассказывай сказочки.На самом деле, опыт работы с ОС Linux, это из разряда "будет плюсом", а вовсе не из "требуются следующие знания и практические умения". То есть в расчет это конечно принимается и приветствуется, но вовсе не является решающим и достаточным доказательством компетенции принимаемого на работу спеца.
А тот кто делает только то, что ему нравится - первый кандидат на вылет, вне зависимости от своей компетенции, просто потому что он - слабое звено в команде, на которое нельзя положиться.
Ну а что до программистов, то поверь, на собеседовании будущего разраба спросят о линуксе (если вообще спросят), в последнюю очередь. А в первую проверят на знания ЯП, шаблонов проектирования, и, - внезапно! - на умение работать с гитом.
> на собеседовании будущего разраба спросят о линуксе (если вообще спросят), в последнюю очередьЭто смотря на какую вакансию. Если нужен разраб под Unix вообще или linux конкретно, с хорошим знанием POSIX, то про винду его точно спрашивать не будут.
Ну, это да.
И зарплаты там очень приличные, - факт.
Вот только таких вакансий не очень-то и много, по отношению к тем же вебовцам.
И спецов таких - тоже, по отношению к тем же вебовцам
> Вот только таких вакансий не очень-то и много, по отношению к тем же вебовцам.С другой стороны, в вебе полно индусских вебмакак готовых писать за $5 в час что угодно. А если тебе что-то не нравится - вместо тебя $5 в час получит вон тот индус, заказ просто уедет ему.
> Я может тебя удивлю, но 90% линуксоидов не ищут работу по вакансиям,
> их работодатели сами зовут. Вакансии для джунов, а там действительно приходится
> учить то что популярно, а не то что нравится.Нужен качественный линуксоид. Не джун. gcc, make, git, posix shell, rpm, dpkg и другие страшные слова. Позвали бы, да некого, и на вакансию никто толковый не отзывается. Где водятся эти элитные 90%, не подскажете?
> Нужен качественный линуксоид. Не джун. gcc, make, git, posix shell,
> rpm, dpkg и другие страшные слова. Позвали бы, да некого, и на
> вакансию никто толковый не отзывается. Где водятся эти элитные 90%,
> не подскажете?Ядерщики -- в parallels, остальные -- в яндексе, у нас и где ещё собсно делать надо. Ещё помогает молодёжь всё-таки брать и помогать подрасти -- у нас в общем-то все умеют полный список тех слов, разве что за исключением dpkg у половины, наверное (но это чисто технический аспект).
Порой помогает, когда люди сами видят, что на конторе происходит что-то интересное, к чему стоит руку приложить. Не день-два видят, да и не год-два. Иные приходят и прикладывают.
Это как вид из окна...
Кто много знает и умеет вакансии постоянно не просматривает, некогда :)
Ну вот я например знаю все эти страшные слова и пользую все перечисленное много лет(для ядра не писал, а юзерспейса на C было немало), но новую работу сейчас не ищу.
И ваще, перелез несколько лет тому назад на Java, все-таки там проще найти что-то оплачиваемое и интересное. Хайтек всякий, например.
> Хайтек всякий, например.что это значит? Продукты на Ява как-то не вяжутся с хайтеком у меня
>> Хайтек всякий, например.
> что это значит? Продукты на Ява как-то не вяжутся с хайтеком у
> меняНу всякие там беспилотники, ИИ, генетика, биохимия.
> Нужен качественный линуксоид. Не джун. gcc, make, git, posix shell, rpm, dpkg
> и другие страшные слова. Позвали бы, да некого, и на вакансию
> никто толковый не отзывается. Где водятся эти элитные 90%, не подскажете?С таким оформлением вакансии и не найдешь никогда, чудак. Опиши требования нормально, контакты оставь. При том желательно указать характер работы. А на просто "нужен работник, повар конюх и плотник".
Вакансия с требованиями и контактами висит на hh вот уже года два. И ещё в каких-то, ведомых только hrам, местах висит. Так что не переживай.
> висит на hh вот уже года два.
> Так что не переживайну как можно, должно же быть хоть какое-то сострадание!
> ну как можно, должно же быть хоть какое-то сострадание!Если бы человек всерьез хотел вакансию закрыть - он хотя-бы ссылку на hh дал, чтоли. А так он просто троллит походу. Пойдите туда не знаю куда, найдите то не знаю что. Вай как все плохо, линуксоидов не найдешь.
> Вакансия с требованиями и контактами висит на hh вот уже года два.Видимо так написано, что люди с работающим мозгом обходят сразу за километр. Могу предположить что у вас там или требований на целую фирму или зарплата смешная. Иных поводов для того чтобы вакансия 2 года висела просто нет.
> Иных поводов для того чтобы вакансия 2 года висела просто нет.Есть, есть. Например, целевые люди вообще не смотрят вакансии. Потому что не ищут работу. Как таких людей находить -- понимать надо самому.
PS: а к нам тем временем пришёл ещё один мегачеловек и поинтересовался другой... обоих давно знаем, никаких собеседований не надо.
>> Иных поводов для того чтобы вакансия 2 года висела просто нет.
> Есть, есть. Например, целевые люди вообще не смотрят вакансии. Потому
> что не ищут работу.Во-во. Говорят же, что хорошие специалисты даже не доходят до рынка вакансий - их перехватывают раньше.
Не они ищут работу, а работа их. Всё это работает через знакомых.
> Ага, умники. 99% вакансий на разраба требуют GITне git, а владения аж двумя командами - push и clone. Но да, все они гордо пишут "владение git".
> , это уже промстандарт. А этим гаврикам не нужно.
потому что когда ты роешься в репо хорошо так подтухших версий, с пятью-десятком параллельных веток (авторов, понятно, давно след простыл - то ли прикопаны в лесополосе, то ли подались в эффективные), пытаясь угадать, где же и в какой из них произошла неведомая херня, внезапно, выясняется, что система, изначально придуманная человеком, ниасилившим ничего, кроме приема патчей почтой, не очень подходит для подобной работы.
> Ок, удачи вам в поиске хорошей работы.
спасибо, конечно, жаль что я плохо верю в чудеса.
> Новая папка 1, Новая папка 2... ваше все.угу. Потому что и 99% "занявших вакансии" разрабов, и их менеджеры, и, к сожалению, даже те кто потом вынужден разгребать гитовый шлак, кроме своего "любимого" гита умеют только "новая папка".
причем git они, разумеется, тоже не умеют, освоив две команды (еще, может, кое-как, rebase, хотя там происходящее для них уже отдает мистикой). За исключением оставшегося 1%, который еще пойди найди где-то.
> что система, изначально придуманная человеком, ниасилившим ничего, кроме приема патчей почтой, не очень подходит для подобной работыа в чём проблема? git - это история файла в виде патчей, типа пазл, со своими плюсами и минусами, и если рассматривать эту систему именно как набор патчей, то работать с ней становится достаточно удобно. но, если попытаться смотреть на git как на прокачанный svn - то начинаются проблемы и непонятки, в этих системах подход к манипулированию изменениями принципиально другой
Git blame не? Историю файла по комитам его затрагивающие нельзя взять? Да и если взяли по веткам какая разница то? Они продолжили его менять? Меняешь в основной, можешь даже ребейзом, и все.
> Git blame не?не. это из другой оперы. Когда просто что-то сломано, причем точно ясно - что именно, и ты можешь написать для этого тест (у hg в этом случае все то же самое)
> Историю файла по комитам его затрагивающие нельзя взять? Да
можно, пользы никакой. Она не линейна.
в общем там, по ссылке на хабр, хороший пример. Если дороешься до реддита - будет неупрощенный, из реальной жизни.
> Меняешь в основной, можешь даже ребейзом, и все.
ну да, я же говорю - для 99% пользователей "владеющих git" существует только текущее состояние.
"а если что не так - мы просто перепишем этот код заново". Пофиг что до тебя пять раз уже переписали.
>> Git blame не?
> не. это из другой оперы. Когда просто что-то сломано, причем точно ясно - что именно, и ты можешь написать для этого тест (у hg в этом случае все то же самое)Вообще-то это git bisect.
И я не понимаю, чего ты хочешь. Кнопку "сделай мне зашибись"?
> потому что когда ты роешься в репо хорошо так подтухших версий, с
> пятью-десятком параллельных веток (авторов, понятно, давно след простыл - то ли
> прикопаны в лесополосе, то ли подались в эффективные), пытаясь угадать, где
> же и в какой из них произошла неведомая херня, внезапно, выясняется,
> что система, изначально придуманная человеком, ниасилившим ничего, кроме приема патчей
> почтой, не очень подходит для подобной работы.Твоя не понимайт!
Тов.Главный прекрасно свёл и "эту работу" к приёму патчей: он таки принимает патчи, исправляющие раннее "произошедшую неведомую ню", а разбираются-угадывают другие.
>99% "занявших вакансии" разрабо
> к сожалению, даже те кто потом вынужден разгребать гитовый шлак, кроме
> своего "любимого" гита умеют только "новая папка".
>оставшегося 1%, который еще пойди найдиСебя ("роешься в репо хорошо так подтухших версий") не похвалишь -- так ведь и никто, и день зря. Категорически!
>не git, а владения аж двумя командами - push и clone. Но да, все они гордо пишут "владение gи слава б-гу! обычно, когда становятся нужны другие команды, значит что-то пошло не так и приходится удалять гланды через задницу.
Вообще-то как минимум checkout -b умеют, даже если все мержи через какой-то визуальный тул вроде гитлаба. И blame.Если гуй есть - то да, джуну/миддлу больше ничегоне нужно, если без него - git log ещё. остальное - rebase, ручной merge, cherry-pick и подобное - тем, кто понимает, что делает, их много не надо.
А так - согласен, чем проще процесс тем меньше шансов начудить.
> rebase, ручной merge, cherry-pick и подобное - тем, кто понимает, что делает, их много не надоЕщё stash забыл. Тоже часто полезная штука.
Не забыл. Полезная фича, да, и сам я к ней привык... Но склонна порождать бардак, лучше локальные ветки плодить.
> Не забыл. Полезная фича, да, и сам я к ней привык... Но
> склонна порождать бардак, лучше локальные ветки плодить.Не, ну bisect еще все-таки нужен, баги им ловить все-таки круто.
Угу, нужен, круто, но слишком сложно для многих. Не сам процесс (он тривиален), а всё, что вокруг него - чтобы оно корректно работало нужен хорошо поставленный процесс чтобы не ловить "хвосты" старых сборок, иметь приемлемое время выполнения одной итерации и обеспечить повторяемые действия по проверке на баг и довольно аккуратную историю с минимумом поломанных коммитов.В общем, в реальной жизни часто проще и быстрее отсечь какой-то диапазон руками (а то и руками QA) и потупить на диффы, а дальше отлаживать обычным образом - логи/дебаггер.
Не понял что там сложного. Сам процесс прост как тапка, все сводится к тому можешь ты стабильно воспроизвести баг или нет. Бывают подлые классы багов которые могут основательно посношать мозг, так что в результате окажется что баг плавающий и был всегда. Но с bisect это станет понятно за десяток итераций по бреду который нашелся. А без него в таком случае вообще мозг сломаешь.
> потому что когда ты роешься в репо хорошо так подтухших версий, с
> пятью-десятком параллельных веток (авторов, понятно, давно след простыл - то ли
> прикопаны в лесополосе, то ли подались в эффективные), пытаясь угадать, где
> же и в какой из них произошла неведомая херня, внезапно, выясняется,
> что система, изначально придуманная человеком, ниасилившим ничего, кроме приема патчей
> почтой, не очень подходит для подобной работы.Эта система позволяет разгрести даже такие конюшни и привести все в приемлемый вид. Конечно, это требует квалификации и (в зависимости от запущенности случая), времени.
Помойку в VCS я видел во вмногих системах, разгребать умею (или умел) в четырёх. В этом смысле мощнее git'а ничего нет.
> система, изначально придуманная человеком, ниасилившим ничего, кроме приема патчей почтой...+1! Вообще не догоняю, как "это" можно называть DVCS! Это ж тупо "патчилка ядра"! :)
Хороший редактор не может родиться на идее "давайте напишем программу движения курсором". DVCS требует очень глубокого проектирования, обсуждения деталей с сотней экспертов, нахождение всех мыслимых use case'ов и их отсев по полезности и т.п.
Что сделал Трольвадс? Просто написал архиватор ревизий! Главное же - ввязаться в бой, а там посмотрим!Я не хочу сказать, что Mercurial намного круче, но то, что он более грамотно спроектирован - точно. Не идеально, но лучше Gыt'а!
> Что сделал Трольвадс? Просто написал архиватор ревизий! Главное же - ввязаться в
> бой, а там посмотрим!Вообще-то он наполовину подсмотрел идею этого. И нет, DVCS - не редактор. И где все твои сотни экспертов? Впахивают пытаясь зачать ребенка за месяц взяв 9 женщин?
> Я не хочу сказать, что Mercurial намного круче, но то, что он
> более грамотно спроектирован - точно. Не идеально, но лучше Gыt'а!Охрененный паттерн проектирования - пытаться мимикрировать dvcs под svn, как будто мир состоит только из необучаемых даунов. Такие hg и стали пользоваться.
> Я не хочу сказать, что Mercurial намного круче, но то, что он более грамотно спроектирован - точно. Не идеально, но лучше Gыt'а!да вы что? Одна работа с ветками в HG стоит того, что бы забыть и не вспоминать. В состав changeset-а входит название ветки! "Это какой-то позор"
Я был "утенком" у HG, т.е. после SVN я начал использовать HG, и долгое время не признавал git, т.к. не было реального проекта. Но после освоение git, которое произошло в другой команде, я понял, что HG - это колодки на ногах.
>> система, изначально придуманная человеком, ниасилившим ничего, кроме приема патчей почтой...
> ж тупо "патчилка ядра"! :)Гоги, дарагой, ты за меня или за медведя?! Полегше с сарказмом-то, его не то что медведь, но и большая половина местных (как тех, кто "за", так и те, что "против"/"усё пропало шеф") не поймут
> Хороший редактор не может
> Что сделал Трольвадс? Просто написалВообще-то он пере-реализовал архитектуру г-на МакВея из БитКиппера.
Просто, да не "просто курсор подвигать".
>архиватор ревизий! Главное же - ввязаться в
> бой, а там посмотрим!
> Я не хочу сказать, что Mercurial намного круче, но то, что он
> более грамотно спроектирован - точно. Не идеально, но лучше Gыt'а!Надо тоньше!
Высмеивать -- так обоих. А то е смешно совсем, запашок странный итпр.
> rebase.abbreviateCommandsСтранно, что не rebase.abbr :)