Представлен (https://lkml.org/lkml/2012/4/6/290) релиз распределенной системы управления исходными текстами Git 1.7.10 (http://git-scm.com/). Git является одной из самых эффективных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории от изменений задним числом используются криптографические методы, также возможна привязка цифровых подписей разработчиков к тегам и коммитам. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux, Perl, Eclipse, GNOME, KDE, Qt, Ruby on Rails, Android, PostgreSQL, X.org,
Некоторые изменения:
- При выполнении "git merge" отныне вызывается интерактивный редактор для добавления пояснения о результирующем слиянии, по аналогии с "git commit". В случае использования "git merge" в скриптах, для отмены нового поведения следует установить переменную окружения GIT_MERGE_AUTOEDIT в значение "no" или использовать опцию "--no-edit";- В настоящее время, если не указать какие ветки и теги использовать при выполнении "git push", используется правило "matching refs" (push.default=matching), которое выбирает для обновления все внешние ветки и теги с именами, совпадающими с локальными. В будущих версиях Git поведение будет изменено и изменения будут затрагивать только текущую ветку (push.default=upstream или push.default=current);
- Обновлён интерфейс gitk, например, переработан диалог настройки и добавлена поддержка наглядного сравнения двух коммитов;- В "gitweb" реализована подсветка результатов поиска, осуществлено чтение из репозитория только необходимых для текущей задачи данных (а не всех которые могут понадобиться для различных задач), обеспечен вывод списка проектов, размещённых в указанной директории;
- В HTTP-транспорте реализована поддержка работы через прокси с аутентификацией;
- В конфигурации добавлена поддержка директивы "include", позволяющей включать в текущую позицию содержимое других файлов;
- Возможность подключения обязательных к применению фильтров контента;
- В "git clone" добавлена поддержка опции "--single-branch" для ограничения клонирования одной веткой;
- При выполнении "git clone" c указанием тега через опцию "--branch" (например, "--branch=v1.0") теперь осуществляется отсоединение HEAD из результирующего репозитория;
- Вывод "git diff --stat" теперь автоматически подстраивается под широкоформатные терминалы и использует максимально возможную ширину строки;
- Обновлён фильтр "diff-highlight" из contrib, который теперь генерирует более эстетически приятный вывод;
- В "fsck" добавлена опция "--no-dangling" для пропуска информации о висящих объектах;
- В операциях "git log -G" и "git log -S" добавлена поддержка опции "-i" для поиска без учёта регистра символов;- В "git push" добавлена опция "--prune" по аналогии с "git fetch";
- Содержимое директории, используемой для хранения первичного проекта, обслуживаемого через "git submodule", теперь может быть перенесено в другое место;
- При выполнении "git tag --list" появилась возможность ограничения вывода только для объекта, указанного через "--points-at object";- Добавлен скрипт "diffall", предназначенный для выполнения за один проход сравнения двух ревизий на уровне содержимого директорий;
- В "git difftool/mergetool" добавлена поддержка DeltaWalker;
- Улучшена работа инструментов для интеграции со сторонними системами: "git-p4", "git-svn", "vcs-svn";
- Увеличена производительность "git fetch" для репозиториев с чрезмерным числом ссылок, за счёт избавления от ненужных вызовов функций парсинга объектов;- В тестовом пакете реализована поддержка параллельного выполнения заданий, что является первым шагом к созданию фреймворка для оценки производительности.
URL: https://lkml.org/lkml/2012/4/6/290
Новость: http://www.opennet.me/opennews/art.shtml?num=33556
может git мощнее и у него больше функций, которые важны очень крупным проектам, однако для простых смертных разработчиков в небольших коллективах удобнее Mercurial + TortoiseHG :)а про git пока так: http://www.youtube.com/watch?v=CDeG4S-mJts - баян, но ржака
У нас абсолютно противоположный опыт. Git подошел лучше чем Mercurial, ветвления рулят :)Хотя на старых проектах оставили Mercurial.
hg bookmarks?
hg kostily-kostiliki
Перейти на git оказалось проще чем использовать bookmarks в Mercurial. В git это изначально заложено и очень прозрачно используется. Хотя bookmarks в одном или двух старых проектах используются сейчас, но что-то ни кто от них не в восторге.
Гит вообще для тех кто хотя-бы hello world написать может и представляет себе как выглядит процесс разработки - ощущается столь же естественно как воздух. Вы просто не задумываетесь когда дышите. В гите я точно так же не задумываюсь насчет типовых операций потребных разработчикам. Они сделаны очевидно и естественно,
Такое ощущение что я читаю рекламу ВидалСасунВошНГо.
> Такое ощущение что я читаю рекламу ВидалСасунВошНГо.Хороший товар - рекламируют благодарные пользователи. Хреновый - куча маркетологов. Видал, Сасун? :)
к сожалению, в случае с гитом, рекламировать могут и толпы восторженных хомякидов, которые альтернатив не видели никогда, но заучили мантры: git, ror, etc.
Ну да, чтобы kernel хакеров обозвать восторженными хомякидами это надо быть как минимум Чаком Норисом.
Это ты тут кернел-хакер?
Так они его для себя создавали. А так да, толпа леммингов не может ошибаться. А Git так и остался коллекцией костылей, вот такой вот linux-way.
> Так они его для себя создавали.Правильно. И кому как не программистам лучше всего знать свои потребности, да?!
> А так да, толпа леммингов не может ошибаться.
О, нормально, оказывается толпа програмеров, включая ядерщиков пингвинуса - лемминги. А это, надеюсь вы завтра уже выкатываете в продакшн вашу более хорошую систему, которая покажет этому пингвину кузькину мать? :)
> А Git так и остался коллекцией костылей, вот такой вот linux-way.
Linux way - это когда вместо дро^W на высокие концепции и теоретизирований инженеры на практике вкалывают и делают все так, чтобы оно работало. Желательно как можно лучше. На практике, а не где-то там в абстрактных теориях, может быть, когда-нибудь.
Чего ты хочешь от любителей? Пишут свой простенький проект и хвалят свои костыли. Вантузятники вон такие же - со своим ущербием носятся аки с писаной торбой и мучаются с мержем.
> которые альтернатив не видели никогда,Им повезло что не видели - меньше блевать от результатов сравнения и сожалеть о потраченном времени на всякое старье будут. Я - видел, как минимум CVS, SVN, HG, BZR. Гит лучшее что попадало мне в лапы из этого списка.
> но заучили мантры: git, ror, etc.
Да я уж понял что солярщики и бcдуны по жизни слоупоки и до них вечно все хорошее доходит лет через 10 после всех остальных. Ну вы там и юзайте эти ваши svn и что там у вас еще, а я сравнил время синка репы svn vs git и прекрасно вижу что git в хренадцать раз быстрее на одной и той же операции.
Хватит сказки рассказывать про Mercurial и TortoiseHG. Ты либо с винды не слез, либо система контроля версий тебе не нужна. В общем видели, знаем, ставим Mercurial, а потом его в git превращаем, только вот ветвлений нормальных там нет и вообще ничего нормального нет.
> Хватит сказки рассказывать про Mercurial и TortoiseHG. Ты либо с винды не
> слез, либо система контроля версий тебе не нужна. В общем видели,
> знаем, ставим Mercurial, а потом его в git превращаем, только вот
> ветвлений нормальных там нет и вообще ничего нормального нет.Если бы не Mercurial я бы с svn бы на git сразу не слез, не тот у меня возраст что бы привычки менять, так что не надо на Mercurial наговаривать, достойная система контроля версий.
И посмотрел бы я на вас как вы без Tortoise будете учить дизайнеров, художников, и других не программистов которые над контентом проекта работать комиты делать.
>И посмотрел бы я на вас как вы без Tortoise будете учить дизайнеров, художников, и других не программистов которые над контентом проекта работать комиты делать.Мордаладонь. А создать им батник/ скрипт вида git add .&&git commit -am "From designer" религия не позволяет? Аналогично для пула/ пуша.
Кстати наблюдения показазывают, что среди дизайнеров/художников дибилов не больше чем в других случаях.
А мержить они как через такие скрипты будут? Нет уж, пусть лучше понимают что делают, а не скрипты запускают, был у нас такой резвый, который скрипты для художников писал, через два дня репозиторий в змея горынычя превратился, только не обычного, а из Чернобыля, с 1000 и 1 головой.
Мерджить должен старший, а не абы кто, предварительно проверив накоммиченную лажу.
Зачем им вообще что-то мержить? Для таких кадров придумали системы резверного копирования. А большего от VCS им и не нужно, ибо такие же заложники привычек по своей воле.
> Зачем им вообще что-то мержить?Более того - объясните мне что с логической точки зрения есть "мерж" двух вариантов растровой картинки? :)
> И посмотрел бы я на вас как вы без Tortoise будете учить дизайнеров, художников, и других не программистов которые над контентом проекта работать комиты делать.Интересно посмотреть на commitdiff при изменении гаммы растровой картинки :)
> Интересно посмотреть на commitdiff при изменении гаммы растровой картинки :)Вообще, использование sourcecode-oriented vcs художниками - это очень загадочная и интересная тема.
душа рэндомщика загадочна...
> Вообще, использование sourcecode-oriented vcs художниками - это очень загадочная и интересная
> тема.Пусть тогда расскажет что должен делать мерж 2 растровых картинок? Давать на выходе рандом? :)
git: 'commitdiff' is not a git command. See 'git --help'.
> Интересно посмотреть на commitdiff при изменении гаммы растровой картинки :)Дизайн макетов в xml, а графика в svg. :) А для бинарных форматов только svn. Идиотизм пихать в git или mercurial такие вещи. Они по дню раз сто меняются, пришлось бы дата центр арендовать хранись это под vcs :)
svn это типа уже не vcs? Кстати, есть хорошая вещь для просто наколеночных бэкапов - git-annex
> svn это типа уже не vcs?Жалкое подобие таковой. Даже на прошлую ревизию не отмотаешь если сети нет.
> Если бы не Mercurial я бы с svn бы на git сразу не слез, не тот у меня возрастВаш возраст и привычки - ваши проблемы. А я вот смотрел их примерно одноврменно. Ну и гадость же hg на фоне git. Одного того что гит в разы быстрее типовые операции отрабатывает уже достаточно. Пока фанаты svn/cvs/git ффтыкают как оно проматывает запрошенную операцию, git уже давно закругляется.
> И посмотрел бы я на вас как вы без Tortoise будете учить дизайнеров, художников, и
> других не программистовНафига козе баян?
>Пока фанаты ...git ффтыкают как оно проматывает запрошенную операцию, git уже давно закругляется.это все происходит с одним и тем же гитом, или с разными)
> это все происходит с одним и тем же гитом, или с разными)В первом случае разумеется hg/svn/cvs. Во втором - гит. После гита эти тормозилки ничего кроме отвращения не вызывают.
> В первом случае разумеется hg/svn/cvs. Во втором - гит. После гита эти тормозилки ничего кроме отвращения не вызывают.Ты этой товарищам из фейсбука расскажи. :-) Они, почему с тобой не советовавщись, рещили, что гит редкое тормозилово :-)
Товарищи из фейсбука еще PHP свой написали, потому что в свое время решили что он няшка. И таки да, то же мне эксперты.
Товарищи из фейсбука как раз эксперты - они поддерживают и разрабатывают свехвысоконагруженную сложную систему и наверное к их мнению стоит прислушаться. А ву с какой опыт?
товарищи из мордокниги — они таки да, эксперты. по костылям и количеству матов, которое надо, чтобы заставить кое-как работать «это долбаное legacy».
AFAIK, другие варианты они даже не тестировали
> Ты этой товарищам из фейсбука расскажи. :-)Это тем которые сначала на пыхпыхе написали а потом подорвались через эн лет делать конвертор в плюсы? Эдак до них через эн лет допрет что альтернативы еще тормознее а они жирафы :)
> И посмотрел бы я на вас как вы без Tortoise будете учить дизайнеров, художников, и других не программистов которые над контентом проекта работать комиты делать.Так вот, специально для такого случая написано:
http://hoth.entp.com/output/git_for_designers.htmlНа очень понятном для "гуманитариев" языке.
> На очень понятном для «гуманитариев» языке.в принципе, там было бы достаточно слова «DON'T!» за очень небольшим исключением там не нужны дифы, мержи, бранчи и прочие страшные слова. всё, что надо — это, фактически, коллекция бэкапов с возможностью дёрнуть любой. то бишь, что-то ещё даже примитивней, чем svn.
Дизайнерам и подобному народу лучше давать централизованный версионник - как правило у них не хватает компетенции нормально администрировать локальный, да и не нужно им оно. Всё что там требуется - место, куда будет валиться очередная версия "нетленки" с подписью, и средства вытащить нужную версию - при это всё это реализованное так, чтобы необратимо поломать будо нереально. То есть либо svn либо если git и иже с ним - то скрипты, которые будут использовать локальный репозиторий исключительно как кэш центрального и пушить на любой чих.
Не надо вот этого, пожалуйста. Возможностей ветвтления в ртути в два раза больше, чем в гите, при этом способов выстрелить себе в ногу вдвое меньше, а интерфейс в разы проще, понятнее и логичнее, что видно даже по мануалам - они втрое короче гитовских. Освоение ртути после CVS у меня заняло полчаса, в гите путаюсь до сих пор, хотя использую и то и другое параллельно.
> после CVSэто просто последствия травмы. меркуриал тоже травмированые делали.
> проектам, однако для простых смертных разработчиков в небольших коллективахЯ уж не знаю чем вам git не угодил, но hg по сравнению с ним - довольно противная штука. Мне категорически не понравился. Типовые операции в гите намного резвее.
> однако для простых смертных разработчиков в небольших коллективах удобнее Mercurial + TortoiseHG :)Настолько удобнее, что мы используем SVN в нашем небольшом коллективе? ;(
> TortoiseHG :)"разработчик" под пиндой это не разработчик.
Только вот их подавляющие большинство. Так что не живите в мире иллюзий.
Дадада. А еще большинство слушает попсу и блатняк и жрет всякую гадость.
У нас в конторе вантузятников хорошо если 3% наберется, так что не надо расписываться за всех.
> Дадада. А еще большинство слушает попсу и блатняк и жрет всякую гадость.Оно же ломится програмить на VB и прочих питонах и считает что это модно и круто, а всякие там гиты не лицом к пользователю :)
> Только вот их подавляющие большинство.Это взаимозаменимые быдлокодеры как правило, от которых требуется в срок гнать древний корпоративный булшит. Разработчик - больно жирное название для таких индивидов. Генератор гогнокода.
АйТи, и кодинг в частности, сейчас стало доступнее. Вполне нормальное явление появление кучи быдлокодеров в профессии. Ну и что что их там куча?
Самое смешное что и такие осваивают гит. Потому что гладиолус^W гитхаб...
>> TortoiseHG :)
> "разработчик" под пиндой это не разработчик.TortoiseHG написан на Python + Qt и в 100% полной мере реализован на windows и Linux
мое мнение таково - скорее Mercurial обрастет фичами из git-а в удобоваримой форме, чем git повернется лицом к пользователю, потому что команды hg - просты и очевидны и всегда работают как задумано, однако заставить git работать как надо - это много гугления, и нет аналога TortoiseHG под Linux
> мое мнение таково - скорее Mercurial обрастет фичами из git-а в удобоваримой
> форме, чем git повернется лицом к пользователю,Писать проект на питоне - это лицом к кому угодно, кроме собственно пользователя программы. Разработчики гнали как на пожар (других вменяемых причин юзать питон нет, ибо тормозное угребище со страшным синтаксисом). Гонка на пожар - была приоритетом #1. Все остальное было вторичным. И да, угребище на питоне никогда не будет быстрым.
Хуже адептов питона только програмеры на VB. Давайте еще расскажем что они ща подорвутся и напишут нормальную VCS. Сразу после питонистов, ага.
> TortoiseHG написан на Python + Qtуже после этого его можно выкидывать.
> чем git повернется лицом к пользователю
а зачем *пользователю* гит? O_O
> потому что команды hg — просты и очевидны и всегда работают как задумано
жаль, задумывал их какой-то внеземной разум. причём его представители, судя по скорости работы hg, живут по пятсот лет.
> однако заставить git работать как надо — это много гугления
O_O
> и нет аналога TortoiseHG под Linux
какая досада! впрочем, я понимаю: hg настолько прост и логичен, что без мышегуёв с ним никак нормально работать нельзя. ну, бывает, чо.
>> TortoiseHG написан на Python + Qt
> уже после этого его можно выкидывать.О, Капитан! Я собственно так и делаю - я теперь по зависимостям чекаю до инсталла: если там светится питон и куча его либ - сразу нафиг, без вариантов.
>> чем git повернется лицом к пользователю
> а зачем *пользователю* гит? O_OНу как, есть гитхаб же, это модно, стильно, молодежно. Видел как им пользуются даже махровейшие виндузятники которые программить то умеют разве что на VB :)
>> потому что команды hg — просты и очевидны и всегда работают как задумано
> жаль, задумывал их какой-то внеземной разум.Это питонисты, сэр!
> причём его представители, судя по скорости работы hg, живут по пятсот лет.
У питонистов один приоритет - они дро^W на скорость разработки.
>> однако заставить git работать как надо — это много гугления
> O_OНаверное это виндузятник и поэтому манов у него нет.
>> и нет аналога TortoiseHG под Linux
> какая досада! впрочем, я понимаю: hg настолько прост и логичен, что без
> мышегуёв с ним никак нормально работать нельзя. ну, бывает, чо.Лично я вообще не осознал нафиг системе контроля версий гуй.
новость не читаем, про gitk ничего не знаем... но неистово комментируем!
Это же Вы не понимаете! Тортуаз - интеграция с Майкрософт Уиндоуз Эксплорером. Нету этой интеграции для линуксов. ОМГ, не-ту!!! </нипанятнаа>
> ТортуазНазвание то какое. Сантехнический узел прямо.
GUI удобен только как смотрелка дерева коммитов, не более.> для простых смертных разработчиков в небольших коллективах удобнее Mercurial + TortoiseHG
феерично каждый день мержить головы
> феерично каждый день мержить головыкак будто у гита нету голов. сказки то че рассказываем? нужен бы был glog в гите, если бы там ветвлений истории не было.
Тем кто и сейчас ничего не понял, вот в помощь несколько выдержек:
****
We immediately lose the concept of version numbers. A downstream consumer has to use the git tools to query if a particular change is present in their stream. That has implications for security alerts as you have to be a git consumer. (Unless they're on a release CDROM image cycle of course.)...
Or the tree is locked while somebody is uploading from a 28.8k modem in the back of Nigeria.
It's not so much an issue for Linus because there are so few committers to the root tree. It's a pull model.
***
Basically, committing to a shared repo with git is really really hostile and not a design feature. It assumes there is somebody like Linus to receive patches in email and merge them into their repo locally and publish the results, rather than having 300 people racing each other to try and get a commit in before their rebased work is invalidated or branches go stale.
****
But git is not designed for hundreds of people pushing to a shared repo with branches.
****
git really is designed with a single committer who publishes their work in mind.
> Тем кто и сейчас ничего не понял, вот в помощь несколько выдержек:
> ...А можно примеры VCS, которые решают приведённые Вами задачи лучше, чем git, по каждому Вашему пункту?
>> Тем кто и сейчас ничего не понял, вот в помощь несколько выдержек:
>> ...
> А можно примеры VCS, которые решают приведённые Вами задачи лучше, чем git,
> по каждому Вашему пункту?SVN, скажем. Поскольку она централизованная, то там как раз используется push model.
Номера версий в SVN, как мы помним, тоже есть. Причём нумеруется там именно репозиторий в целом, а не отдельные файлы (как в CVS). То есть номер версии однозначно определяет состояние репозитория.
Я не уверен насчёт случая с Нигерией, поэтому не буду врать.
Однако то, что пушить в SVN можно действительно сразу нескольким людям, и это не будет вызывать конфликтов (если они не трогают одни и те же файлы) -- это действительно чистая правда :-)Со скоростью у SVN неважно по сравнению с гитом, это да. Но это тот случай, когда в целом годную модель можно извратить до состояния SVN. Это отнюдь не означает, что все централизованные VCS -- зло. Просто каждый инструмент решает свою задачу.
К сожалению, многие этого понять не могут, отсюда -- такое количество фанатов git.
>>> Тем кто и сейчас ничего не понял, вот в помощь несколько выдержек:
>>> ...
>> А можно примеры VCS, которые решают приведённые Вами задачи лучше, чем git,
>> по каждому Вашему пункту?
> SVN, скажем. Поскольку она централизованная, то там как раз используется push model.
> Номера версий в SVN, как мы помним, тоже есть.Принято. (только я не понимаю в чём прелесть именно r12345; это хоть сколько-нибудь информативно только при линейной истории).
> То есть номер версии однозначно определяет состояние репозитория.
Ну, это как бы сильно на любителя: толи нет бранчей, тэгов, etc., толи side-эффект --- как неявно зацепить все ветки.
> Однако то, что пушить в SVN можно действительно сразу нескольким людям, и
> это не будет вызывать конфликтов (если они не трогают одни и
> те же файлы) -- это действительно чистая правда :-)Любимый пример: пробовали ли Вы работать с чем-нибудь монструозным типа boost's (boost.org) SVN? Мне не понравилось (мягко скажем).
> Со скоростью у SVN неважно по сравнению с гитом, это да. Но
> это тот случай, когда в целом годную модель можно извратить до
> состояния SVN. Это отнюдь не означает, что все централизованные VCS --
> зло. Просто каждый инструмент решает свою задачу.Любую DVCS можно использовать в режиме 'с центральным репозиторием'.
> К сожалению, многие этого понять не могут, отсюда -- такое количество фанатов
> git.Я не обнаружил разумных вариантов, когда SVN имел бы преимущество над git. А когда он принёс кучу проблем --- довольно много.
Спасибо за ссылку выше. Прискорбно, что разрабы от FreeBSD имеют такую точку зрения. Классная система и команда, но взляды немного закостенели.> ... shared repo ...
Этим всё сказано. Просто чуваки привыкли работать с централизованым репозиторием. А когда постомрели на git - поняли, что он им не подходит. А почему не подходит? А потому, что заточен для де-централизованной работы. Вот ведь неожиданность: средство для де-централизованной работы не подходит для централизованной работы! Удивительно, да?
Вывод вполне ожидаем - если хотите централизации, то git не для вас. Впрочем, вывод не нов, и об этом уже везде много раз сказано.
> Классная система и команда, но взляды немного закостенели.В чём это выражается?
Простая истина состоит в том, что инструмент выбирается под задачу, а не наоборот. При переходе на $NEWVCS модель работы не должна кардинально меняться.>> ... shared repo ...
> Этим всё сказано. Просто чуваки привыкли работать с централизованым репозиторием. А когда
> постомрели на git - поняли, что он им не подходит. А
> почему не подходит? А потому, что заточен для де-централизованной работы. Вот
> ведь неожиданность: средство для де-централизованной работы не подходит для централизованной
> работы! Удивительно, да?Не очень понятен Ваш сарказм. Была поставлена задача -- уйти с CVS и найти что-то более удобное для работы централизованной команды.
Было проведено исследование: http://wiki.freebsd.org/VersionControl
Из него видно, что наиболее подходящие кандидаты -- это SVN и git.
Далее уже обсуждение достоинств и недостатков. В итоге -- SVN был выбран, и не в последнюю очередь из-за GitDrawbacks.> Вывод вполне ожидаем - если хотите централизации, то git не для вас.
> Впрочем, вывод не нов, и об этом уже везде много раз
> сказано.Да. Только, тем не менее, воены Света и git-а так и продолжают флудить в темах про новые версии VCS на Опеннете :-) Хорошо, что это так и остаётся флудом в форумах. Иначе мир бы давно был порабощён GPL, Linux и Бог знает чем ещё.
> Не очень понятен Ваш сарказм. Была поставлена задача -- уйти с CVS и найти что-то более
> удобное для работы централизованной команды.
> Было проведено исследование: http://wiki.freebsd.org/VersionControl
> Из него видно, что наиболее подходящие кандидаты -- это SVN и git.
> Далее уже обсуждение достоинств и недостатков. В итоге -- SVN был выбран, и не в
> последнюю очередь из-за GitDrawbacks.Порадовало:
<snip>
Ability to work offline -- like on a plane -- without requiring too much work: not only being able to list differences but also to commit
</snip>--- твёрдое Yes для SVN. ;-)
В http://wiki.freebsd.org/VCSWhy есть очень эмоциональная заочная полемика с Линусом.
Из неё получается, что "Линус в общем-то прав, но мы испытываем к нему такую неприязнь, что кушать не можем; поэтому что угодно, только не git; а если возьмём hg, то там есть ещё несколько проблем, но самое неприятное, он идеологически сходен с git, а нам неприятен не только Линус, но и идеи, похожие на идеи Линуса".Как-то так, а GitDrawbacks ни разу не означают, что этих недостатков нет у других VCS.
Не знаю где они в Git углядели идеи Линуса. Все идеи Git, да и mercurial тоже, были взяты из monotone и bitkeeper. Линус обычно не создаёт чего-то принципиально нового.