Представлен (https://lkml.org/lkml/2011/9/30/406) релиз распределенной системы управления исходными текстами Git 1.7.7 (http://git-scm.com/). Из-за недоступности инфраструктуры kernel.org, код нового релиза временно размещен (https://code.google.com/p/git-core/) на хостинге Google Code, копия создана на SourceForge (http://sourceforge.net/projects/git-core) и GitHub (https://github.com/gitster/git). В качестве подтверждения, что релиз не подделка, мэйнтейнер проекта Junio C Hamano указал на необходимость проверки цифровой подписи.
Некоторые изменения:
- Скрипты подготовлены для интернационализации и локализации (i18n/l10n);
- Обновлены порты для Interix, Cygwin и Minix;
- Разнообразные обновления для git-p4 (в contrib/), fast-import и git-svn;
- Gitweb теперь в первую очередь пытается прочитать файл конфигурации /etc/gitweb-common.conf и уже потом gitweb_config.perl и /etc/gitweb.conf;
- При выполнении команды "git am" (загрузка серии патчей из почтового ящика) в связа...URL: https://lkml.org/lkml/2011/9/30/406
Новость: http://www.opennet.me/opennews/art.shtml?num=31912
> Обновлены порты для Interix, Cygwin и Minix;Это интересно. Насколько сейчас полноценен гит под вендой?
Вполне, юзабелен. Git - он и в Африке Git.
Проблемы с кодировками сущетвуют. Не работает юникод в названии файлов.
А РаЗнЫе РеГиСтРы в именах файлов работают? А то в *nix можно запросто создать Readme.txt и readme.txt в одной дире, а вот у виндов по этому поводу будет butthurt.
Гит с этим ничего не может сделать. Вендопроблемы.
какие проблемы? ntfs - case sensitive и поддерживает Юникод еще аж с момента своего появления (ой, кажется, это 1993 год, за - ээээ - 11 или 12 лет до гита). Не-не, я очень люблю гит, но вендой я тоже не брезгую
> какие проблемы? ntfs - case sensitive и поддерживает Юникод еще аж с
> момента своего появленияДа, только по дефолту для виндов Readme.txt и readme.txt - один и тот же файл, а то что оно там в теории может - блин, какой процент юзеров вообще знает как и где это включить? Кроме того это не поддерживается большинством софта привыкшего к нечувствительности регистра. Совсем не факт что виндовые архиваторы правильно поймут наличие в 1 дире Readme.txt и readme.txt наприер.
Нормально. УМВР.
Используем более 2х лет. Отлично работает.
Под win как обычно костыли с каким то окружением.
Hg как бальзам послан был, выручает везде.
все-таки Mercurial умеет все то же самое, легко портируется на любую ОС, одинаково развитый GUI под все ОС, прост в использовании и более логичная продуманная архитектура для простого примененияMercurial == Git++
Из вашего сообщения следует, что вы используете исключительно mercurial, с git сталкивались пару раз, и он, в виду опыта работы с hg, не понравился...
Именно так и надо было написать, я не пытаться завуалировать ваше отношение и опыт умными словами.
Из вашего сообщения следует, что вы используете исключительно git, с mercuria сталкивались пару раз, и он, в виду опыта работы с git, не понравился...
Именно так и надо было написать, я не пытаться завуалировать ваше отношение и опыт умными словами.
Сталкивался с обоими, гит показался как-то дружественнее и логичнее. Ы?
Сталкивался с обоими, дружественнее и логичнее оказался mercurial
Расскажите это счастливым пользователям subversion.
>Расскажите это счастливым пользователям subversion.А они когда-нибудь сталкивались с DVCS?
Судя потому, что они все еще пользуются svn, нет.
>>Расскажите это счастливым пользователям subversion.
> А они когда-нибудь сталкивались с DVCS?
> Судя потому, что они все еще пользуются svn, нет.Это был всего лишь тонкий намек на то, что я почему-то после cvs/svn, взяв hg изкаробки, просто сел и работал, почитав 20 минут туториал. Т.к. набор команд и юзкейс если и изменились, то незначительно. С git-ом же после двухдневной е..ли желание связываться пропало начисто. Остальное вы сможете найти в комментариях develop7.
>>>Расскажите это счастливым пользователям subversion.
>> А они когда-нибудь сталкивались с DVCS? Судя потому, что они все еще пользуются svn, нет.
> Это был всего лишь тонкий намек на то, что я почему-то после cvs/svn, взяв hg изкаробки, просто сел и работал, почитав 20 минут туториал.Всё, ну решительно всё Делают Не Так. Как вас только земля носит, еретики? </irony>
:-D
> Расскажите это счастливым пользователям subversion.А некоторые вообще до сих пор с деревянными копьями бегают и счастливы.
> Расскажите это счастливым пользователям subversion.ну, вот я был пользователем subversion. никогда она мне не нравилась и не казалась удобной. впрочем, я несчастливый пользователь.
> Из вашего сообщения следует, что вы используете исключительно mercurial, с git сталкивались
> пару раз, и он, в виду опыта работы с hg, не понравился...
> Именно так и надо было написать, я не пытаться завуалировать ваше отношение
> и опыт умными словами.ну вот взять меня. я переехал на git с subversion. тогда я уже знал о существовании DVCS, их преимущества и в принципе был не против переехать.
Поработал с git полгодика на живом проекте. Потратил тучу времени зря на вкуривание манов и терминологии. Два раза штатными средствами сломал репу, один раз — на гитхабе. Оказалось, что силами казуального юзера (которому некогда мастурбировать^W восхищаться gitом и сутками читать маны) самостоятельно разработать и внедрить workflow, отличный от commit => pull => merge => push, невозможно без отрыва от основной деятельности на срок порядка двух дней. И даже после этого уверенности в том, что оно работает надёжно, нет — постоянно ждёшь подвоха и убиения котяток.После полугода хождения по этому минному полю очень обрадовался поводу начать использовать mercurial (в новом проект). О чём так и не представилось случая пожалеть с середины 2008. Mercurial понятен интуитивно, не требует знаний о кишках СКВ, встроенный help лаконичен и исчерпывающ для комфортной работы. Плюс расширения.
Искаробочный mercurial практически дублирует (а кое-где (mq, acl) и перекрывает) функционал git. Используя hg-git, вполне себе возможно *прозрачно* работать с репозиториями git (нет, *не* отдельной командой, как git-svn).Так что лично я не вижу ничего предосудительного в нежелании разбираться в сортах фекалий. Предыдущий комментатор всё правильно сделал.
я напишу меньше текста. 2.5 года, переехали с свн на гит. проекты от мегабайта исходников и выше. бида — не разу ничего не терялось. зато у пары ключевых девелоперов терялись инеты на два-три дня (ну, так вышло; нет, не индусы). с свн в этом были траблы. с гит — не было. 100% (>15) девелоперов сказали, что гит няша. и что hg (был дан выбор) не рулит — по разным причинам. все остались на гите. такие дела.я не агитирую. я тупо рассказываю use case. про hg ничего плохого сказать не могу: не юзал. может, оно круче. но порог вхождения для девелоперов оказался меньше в гите.
если чо: от студиохуса за досирак до дядек за 40 лет. вердикт был: гит.
>> и что hg (был дан выбор) не рулит — по разным причинамА хоть одну вменяемую можно привести? И желательно технологическую, а не слюни типа "никто не умел, ну мы и не перешли"
> А хоть одну вменяемую можно привести?пожалуйста (гит тоже никто не умел, кстати): оно ТОРМОЗИТ. после гита плакать хочется.
>> А хоть одну вменяемую можно привести?
> пожалуйста (гит тоже никто не умел, кстати): оно ТОРМОЗИТ. после гита плакать
> хочется.ага, помню, жаловался на тормоза один деятель. начали копать — выяснилось, что тормозит не CLI, а redmine с плагином Mercurial. Раскопали плагин — оказалось, что оно вызывает hg с параметром --debug. Который отключает куски, написанные на C. Плохой, негодный mercurial, да.
cool story, bro! возьми пирожок.
> cool story, bro! возьми пирожок.а вот ещё cool story — http://mac.github.com/ использует http://libgit2.github.com/. вопрос — почему они не используют git cli, «как нааармальные люди», и почему в природе до сих пор нет libgit(1)?
Пользуюсь hg (Mercurial) в проекте порядка 1 миллион строк кода, Windows. Заявляю авторитетно - не тормозит.
Также пробовал GIT. Что сказать - хорошая VCS. Нравится концепция, с удовольствием прочитал книгу. Единственное, с Windows плохо дружит: кодировки, EOL, прочее. GUI иногда слетает с ошибками (опять же Windows). Немного раздражает запоминать хэши (хоть и частично), все-таки нумерация коммитов в Mercurial удобнее.
А вообще, Линус Торвальдс очень харизматичный человек. С удовольствием слушаю его интервью, а Git on GoogleTalk - хорошой образец жанра. Он смог убедить многих в том, что использовать его продукт могут только самые умные. Типа, Git - это как скальпель в руке у хирурга. И я не спорю, Git действительно хорош. Но Mercurial чуточку лучше и в этом "чуточку" вся суть. Конечно, это мое субъективное мнение.
> Windowsдальше, в принципе, читать не обязательно.
> Пользуюсь hg (Mercurial) в проекте порядка 1 миллион строк кода, Windows. Заявляю авторитетно - не тормозит.этого не может быть. потому что этого не может быть никогда. ясно же выше сказали — тормозит. лично я, конечно, с тормозами не сталкивался, но раз сказали — значит не врут.
> Типа, Git - это как скальпель в руке у хирурга. И я не спорю, Git действительно хорош.выше нам уже убедительно доказали, что Git — лучшее, что придумало человечество.
> Но Mercurial чуточку лучше и в этом "чуточку" вся суть.Этого тоже не может быть, потому что см. выше.
> Конечно, это мое субъективное мнение.ещё бы. вы же смеете усомниться в том, что git — лучшая dvcs
</sarcasm>
> Он смог убедить многих в том, что использовать его продукт могут только самые умные.кстати да. красиво сыграл на ЧСВ.
это всё, без сомнения, важно и интересно, но я вот до сих пор не могу понять одной вещи: как у *D*VCS может быть нумерация изменений a-la svn. или её нет (да-да, хэши в гите не просто так сделаны) и она очень криво эмулируется, или это на самом деле не *D*VCS. такие дела.p.s.: да-да, я знаю про то, что в hg встроен кривучий эмулятор. и это один из примеров того, что авторы hg вообще не понимают, что такое DVCS, как оно должно работать и как это использовать.
Нумерация 0,...,n существует только в локальном репозитории и имеет смысл только для него. Она существует как временно дополнение к хэш-ноду (который уникален по всем репозиториям)
Удобно для, так сказать, для "ah hoc" операций над ревизиями - простмотреть историю "от и до", переместить changeset (aka rebase), и прочее.
штука в том, что она вовсе смысла не имеет, нигде.
Может она не "необходима" для полноты алгебры операицй над репозиториями, но это очень удобно, поверьте.
> p.s.: да-да, я знаю про то, что в hg встроен кривучий эмулятор.если запомнить (вы можете выжечь у себя на руке), что «порядковые номера changesetов — для локального использования», жить становится намного проще.
> если запомнить (вы можете выжечь у себя на руке), что «порядковые номера
> changesetов — для локального использования», жить становится намного проще.тут вот какое дело: они не нужны *ни для какого* использования. единственная причина их существования — нежная любовь авторов hg к svn-подобным системам. ну, и традиционная боязнь переучиваться, ведь столько лет до этого жили с красивенькими номерами, а тут вдруг хэши! ужас! паника на корабле! срочно запилить назад номера, пока не случилось Страшное!
вот потому я и говорю, что hg — defective by design. потому что пытается эмулировать не просто ненужные, а вредные фичи.
>> если запомнить (вы можете выжечь у себя на руке), что «порядковые номера
>> changesetов — для локального использования», жить становится намного проще.
> ну, и традиционная боязнь переучиваться, ведь столько лет до этого жили с красивенькими номерами, а тут вдруг хэши! ужас! паника на корабле! срочно запилить назад номера, пока не случилось Страшное!отучайтесь проецировать собственные комплексы на незнакомых людей.
локальные номера ревизий полезны, т.к. ими удобнее оперировать без подглядывания в hg log. ну и приблизительное местоположение новоприбывших коммитов видно с одного взгляда.
> Пользуюсь hg (Mercurial) в проекте порядка 1 миллион строк кода, Windows. Заявляю
> авторитетно - не тормозит.Учитывая с какой скоростью работает NTFS - там что угодно "не тормозит", только после ext4 этим пользоваться совершенно невозможно, с души воротит от разницы в скорости, ессно не в пользу винды.
> пожалуйста (гит тоже никто не умел, кстати): оно ТОРМОЗИТ. после гита плакать хочется.Ну так питонисты против олдскульных перцев же. Понятно кто зарулит. С закрытыми глазами 100 баксов на олдскульных волков ставлю, они делают "как эффективнее" а не "на питоне".
> и что hg (был дан выбор) не рулит — по разным причинам.ага, знаем. 95% считают, что если вывод не раскрашен, значит это невозможно. и пофиг, что это включается одной строкой в любом конфиге. тоже мне инженеры.
> про hg ничего плохого сказать не могу: не юзал. может, оно круче. но порог вхождения для девелоперов оказался меньше в гите.
в моём случае порог вхождения оказался ниже с HG. собссно, куда уж ниже — нормально работал уже через день подглядывания в первую попавшуюся шпаргалку. причём ровно столько же mercurial осваивал коллега, который кроме svn вообще ничего в жизни не юзал.
мой вердикт — если в команде нет гуры (или хотя бы опытного юзера) git, непроизводительные потери времени гарантированы чуть менее, чем полностью.
> мой вердикт — если в команде нет гуры (или хотя бы опытного
> юзера) git, непроизводительные потери времени гарантированы чуть менее, чем полностью.значит, мы всё сделали не так. потому что гуры не было, а я в процесс не вмешивался вообще.
>> мой вердикт — если в команде нет гуры (или хотя бы опытного
>> юзера) git, непроизводительные потери времени гарантированы чуть менее, чем полностью.
> значит, мы всё сделали не так. потому что гуры не было, а я в процесс не вмешивался вообще.значит, сотни времени спустили в унитаз. git всегда берёт своё — чаще всего временем и ресурсами на запоминание ненужных протекающих абстракций. впрочем, фанбоям не привыкать.
> значит, сотни времени спустили в унитаз.(пожимает плечами) я так понимаю, hg впитывают с молоком матери. а ты — крутой телепат и провидец прошлого.
>> значит, сотни времени спустили в унитаз.
> (пожимает плечами) я так понимаю, hg впитывают с молоком матери. а ты — крутой телепат и провидец прошлого.почему с молоком? я после git вкурил hg за один рабочий день. остальные вопросы разрешались максимум однократным чтением hg help.
> почему с молоком? я после git вкурил hg за один рабочий день.
> остальные вопросы разрешались максимум однократным чтением hg help.а я — гит вкурил меньше, чем за день. и что это доказывает, кроме того, что мы оба умеем читать?
> а я — гит вкурил меньше, чем за день. и что это
> доказывает, кроме того, что мы оба умеем читать?Бывает так что берешь в руку инструмент и он в руке как влитой. Вот git - именно такой инструмент, только для мозгов :). По большому счету я в него вообще почти не вкуривал - посмотрел как им другие пользуются и стал так же. Чего там день делать то?!
Ну единственное что надо забыть всякое барахло типа cvs и svn как страшный сон.
> Чего там день делать то?!черри-пики, бисекты, бранчи и прочие вкусные ништяки, которые на svn стараешься юзать только в самом крайнем случае (или их и вовсе нет). плюс — привычка таки читать маны до того, как накосячишь, а не после. %-)
> Mercurial == Git++судя по «c++», меркуриал — это перегруженый ненужными фичами, дико тормозной и раздутый git. в принципе, правда, наверное.
Выбор чаще диктуется подсознательными стереотипами, чем чистым анализом.
Python - медленно
C/C++ - быстро
На этом основан настоящий холивар Git vs Mercurial. Также как раньше говорили: "Настоящие программисты не пишут на Pascal", можно перефразировать: "От VCS, написанной на Python, ничего хорошего ждать нельзя".
Лично мне нравятся обе системы с перевесом в Mercurial (нативная поддержка веб, расщиряемость, настоящая кросплатформенность).И еще мне немного обидно за Mercurial, Линус все время пытается сделать вид, что его нет. Даже по версии Linux Journal (2010):
1. Git
2. SVN
3. CVS
4. Mercurial
(no comments)
> Линус все время пытается сделать вид, что его нетвсё проще: hg просто defective by design. вот и всё.
Git и Mercurial имеют очень похожую архитектуру (design). Различия в основном в несущественных деталах и в инструментах реализации (преславутый C vs Python).
Кстати, концепция очень хорошо (почти математически) описана в книше "Version Control with Git".
> Git и Mercurial имеют очень похожую архитектуру (design).дьявол, как обычно, в мелочах. а так — все dvcs более или менее похожи, потому что делают одно и то же.
>> Линус все время пытается сделать вид, что его нет
> всё проще: hg просто defective by design. вот и всё.ага. и вовсе это никакой не butthurt. нисколечко.
олсо про defective design кто бы говорил. даже mercurial с bzr гораздо более unix-way, чем кучка скриптов, которая по странному капризу Линуса справляется с функциями системы контроля версий.
> ага. и вовсе это никакой не butthurt. нисколечко.неа. просто попытка понять марсиан на костылях.
>> ага. и вовсе это никакой не butthurt. нисколечко.
> неа. просто попытка понять марсиан на костылях.не знаю, что вы там пытались сделать. git на мой взгляд — такая же злая шутка марсиан, как C++.
и да, по поводу git недоunixway возражений нет?
> и да, по поводу git недоunixway возражений нет?а я не фанат «юниксвея во все поля». в случае с гитом меня вполне устраивает как есть. заметь, что про «юниксвэй» по отношению к hg я тоже не говорил. и вовсе не потому, что «гит не юниксвэен», а потому, что это совершенно не важно. честно — никогда не читал исходники гита. и не читал бы исходники hg точно так же. и там, и там есть коммит-хуки и прочие ништяки (ведь в hg есть?), этого достаточно.
Да вообще-то гит прямо инкарнация юниксвея: кучка супербыстрых утилит связаны скриптовым glue code. Куда уж юниксвейнее?!?
> Да вообще-то гит прямо инкарнация юниксвея: кучка супербыстрых утилит связаны скриптовым glue code. Куда уж юниксвейнее?!?Вообще-то есть куда.
юниксвейнее — это наваять libgit, биндинги к ней и кучку фронтендов на любой вкус. даже у гонимого здесь subversion такая архитектура. отчего оно и прикручивается к любой софтине с полпинка. в отличие от кучек скриптов на си с перлом.
Кстати, наличие в природе libgit2 (которую разрабатывают ребята с github) какбэ намекает.
юниксвейнее — это не гадить в консоль после каждого коммита.
юниксвейнее было бы, если бы хотя бы один workflow scenario обходился голыми командами (без ключей).
юниксвейнее было бы, если бы эти утилиты были предназначены для пользователя, а не для собственных нужд. проверочный вопрос — как давно вы запускали git upload-pack?Учите матчасть.
> юниксвейнее — это наваять libgit, биндинги к ней и кучку фронтендов на
> любой вкус.вперёд, чо.
> отчего оно
> и прикручивается к любой софтине с полпинка. в отличие от кучек
> скриптов на си с перлом.вот странно: у всех прикручивается, даже гуя спокойно используют, а у develop7 не прикручивается. весь строй не в ногу идёт?
> Кстати, наличие в природе libgit2 (которую разрабатывают ребята с github) какбэ намекает.
…на то, что у маководов проблемы с перлом из коробки и вообще с юникс-лайковостью их системы.
> юниксвейнее — это не гадить в консоль после каждого коммита.ORLY? >/dev/null
> юниксвейнее было бы, если бы хотя бы один workflow scenario обходился голыми
> командами (без ключей).у нас, в настоящих ос, есть shell aliases. а ещё google://git+aliases сюрпрайз, да?
> юниксвейнее было бы, если бы эти утилиты были предназначены для пользователя, а
> не для собственных нужд.это как? O_O какого «пользователя»? они предназначены для программистов, которые активно используют DVCS. а тебе обязательно свистелки, перделки и полупрозрачные окна, без этого жизнь не мила? так напиши себе, если время девать некуда. нормальному программисту это не нужно и даже неудобно. а в emacs (и vim тоже, по-моему) git интегрирован вполне нормально.
> проверочный вопрос — как давно вы запускали git upload-pack?
я вот — никогда. ни разу не понадобилось. а тебе понадобилось? зачем?
> Учите матчасть.
вот именно. «чем кумушек считать, рядиться…»
>> юниксвейнее — это наваять libgit, биндинги к ней и кучку фронтендов на любой вкус.
> вперёд, чо.а вот и «это не нужно». но фанбой здесь по-прежнему я, угу.
>> отчего оно и прикручивается к любой софтине с полпинка. в отличие от кучек скриптов на си с перлом.
> вот странно: у всех прикручивается, даже гуя спокойно используют, а у develop7 не прикручивается. весь строй не в ногу идёт?будете писать UI к git сами — обязательно расскажите, как круто и реюзабельно парсить регэкспами stdout git.
>> Кстати, наличие в природе libgit2 (которую разрабатывают ребята с github) какбэ намекает.
> …на то, что у маководов проблемы с перлом из коробки и вообще с юникс-лайковостью их системы.вообще-то для libgit2 есть 100500 биндингов. когда как для "github for mac" нужен только один. что какбэ намекаэ.
и вообще, libgit2 писался для собственных нужд. потому, что ванильный git непригоден для использования на серверах — слишком большой оверхед.>> юниксвейнее — это не гадить в консоль после каждого коммита.
> ORLY? >/dev/nullво-первых,
> Правило тишины: Если программе нечего сказать, пусть лучше молчит.Mercurial после commit молчит. Bzr молчит. git — гадит.
Также почему-то вспоминается старый советский анекдот:
— (в магазине) А почему дуршлаг без дырок?!
— Сам пробьёшь, небось руки не отвалятся!>> юниксвейнее было бы, если бы хотя бы один workflow scenario обходился голыми командами (без ключей).
> у нас, в настоящих ос, есть shell aliases. а ещё google://git+aliases сюрпрайз, да?дуршлаг без дырок
>> юниксвейнее было бы, если бы эти утилиты были предназначены для пользователя, а не для собственных нужд.
> это как? O_O какого «пользователя»? они предназначены для программистов, которые активно используют DVCS. а тебе обязательно свистелки, перделки и полупрозрачные окна, без этого жизнь не мила? так напиши себе, если время девать некуда. нормальному программисту это не нужно и даже неудобно. а в emacs (и vim тоже, по-моему) git интегрирован вполне нормально.отучайтесь переносить собственные комплексы на незнакомых людей. что, программист — уже не пользователь? и меня, мягко говоря, смущает 120 команд, из которых максимум четверть в состоянии сделать что-то полезное самостоятельно, без скармливания им в stdin сотен недокументированных данных.
>> проверочный вопрос — как давно вы запускали git upload-pack?
> я вот — никогда. ни разу не понадобилось. а тебе понадобилось? зачем?и я никогда. а команда есть. а зачем она юзеру?
>> Учите матчасть.
> вот именно. «чем кумушек считать, рядиться…»я опираюсь на определение UNIX way Эрика Реймонда — http://ru.wikipedia.org/wiki/UNIX_way#.D0.A0.D0.B5.D0.B9.D0....
А вы?
> я опираюсь на определение UNIX way Эрика РеймондаА мы -- на здравый смысл. Реймонд, видите ли, не пророк, да и UNIX way -- не жупел, а хорошо проработанный и доказавший свою полезность подход; что не даёт поводов ставить его на пьедестал.
>> я опираюсь на определение UNIX way Эрика Реймонда
> А мы -- на здравый смысл. Реймонд, видите ли, не пророк, да и UNIX way -- не жупел, а хорошо проработанный и доказавший свою полезность подход; что не даёт поводов ставить его на пьедестал.не пророк. он «всего лишь» намного более опытный программист.
И мне по-прежнему непонятно, зачем git commit говорит в stdout вот такое вот:
>[master (root-commit) e7a6196] qwe
> 0 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 a
> не пророк. он «всего лишь» намного более опытный программист.и что? есть подозрение, что у тебя ГСМ. собственно, слово «подозрение» я тут вставил чисто из вежливости.
> И мне по-прежнему непонятно, зачем git commit говорит в stdout вот такое
> вот:не нравится — отключи.
>у тебя ГСМГорюче-смазосные? Марш перечитывать Луркоморье! :))
>>у тебя ГСМ
> Горюче-смазосные? Марш перечитывать Луркоморье! :))вообще-то — если не ошибаюсь — термин придумал Луговский, задолго до этого вашего уютненького.
При чём тут "придумал"? Википедия с Гуглем тоже терминов не выдумывают--- Если бы это чему мешало...
> а вот и «это не нужно». но фанбой здесь по-прежнему я, угу.скажи, где тебе так травмировали мозг, что предложение написать (это ж ты страдаешь без libgit, а не я — ты и пиши) ты воспринимаешь как «это не нужно»?
> будете писать UI к git самизачем?
> обязательно расскажите, как круто и
> реюзабельно парсить регэкспами stdout git.вполне нормально.
> и вообще, libgit2 писался для собственных нужд. потому, что ванильный git непригоден
> для использования на серверах — слишком большой оверхед.и? понадобилось — написали. в чём, собственно проблема и откуда такой батхёрт? что сразу на тарелочке не выкатили? так не надо было тогда.
> во-первых,
>> Правило тишины: Если программе нечего сказать, пусть лучше молчит.а в данном случае есть что сказать. к тому же я, например, с этим правилом не согласен совершенно, и предпочитаю правило «программа должна отчитываться о том, что делает, а затыкать её можно ключом -q». «правило тишины» пригодно только для самых простых утилит, а git этим не является.
> Mercurial после commit молчит. Bzr молчит. git — гадит.
(пожимает плечами) google://git-alias, исправь. в чём проблема-то? авторы гита (и я тоже) считают, что лучше не молчать.
> дуршлаг без дырок
а, я понял: ты из противников настроек в программах, всё должно быть «искаропки». небось, Lua и Scheme тоже за языки не считаешь, потому что они предоставляют механизмы, а не реализации. это, в принципе, «конфликт» code monkeys и programmers. первые предпочитают, чтобы было как можно больше реализаций, а вторые — чтобы дали простые механизмы для создания своих реализаций. собственно, штришок к портрету типичного пользователя hg.
> отучайтесь переносить собственные комплексы на незнакомых людей. что, программист —
> уже не пользователь? и меня, мягко говоря, смущает 120 команд, из
> которых максимум четверть в состоянии сделать что-то полезное самостоятельно, без скармливания
> им в stdin сотен недокументированных данных.см. выше про code monkey vs programmer.
> и я никогда. а команда есть. а зачем она юзеру?
«дядя Петя, вы дурак?» (ц) опять code monkey vs programmer.
> я опираюсь на определение UNIX way Эрика Реймонда
> А вы?а я — на своё. выразить можно очень просто: важны механизмы, а не реализации. имея нужные механизмы, любую желаемую реализацию можно собрать практически «из кубиков». опять code monkey vs programmer.
>> а вот и «это не нужно». но фанбой здесь по-прежнему я, угу.
> скажи, где тебе так травмировали мозг, что предложение написать (это ж ты страдаешь без libgit, а не я — ты и пиши) ты воспринимаешь как «это не нужно»?да не сказать, что так сильно страдаю. за потраченные впустую ресурсы обидно.
>> обязательно расскажите, как круто и реюзабельно парсить регэкспами stdout git.
> вполне нормально.я про интеграцию git в что-нибудь сложнее шеллскриптов.
>> и вообще, libgit2 писался для собственных нужд. потому, что ванильный git непригоден для использования на серверах — слишком большой оверхед.
> и? понадобилось — написали. в чём, собственно проблема и откуда такой батхёрт? что сразу на тарелочке не выкатили? так не надо было тогда.да всегда надо было. просто git начинался как фреймворк, а сейчас позиционируется как vcs. вот и торчит легаси изо всех дыр. а хомячки едят да нахваливают.
>> во-первых,
>>> Правило тишины: Если программе нечего сказать, пусть лучше молчит.
> а в данном случае есть что сказать. к тому же я, например, с этим правилом не согласен совершенно, и предпочитаю правило «программа должна отчитываться о том, что делает, а затыкать её можно ключом -q». «правило тишины» пригодно только для самых простых утилит, а git этим не является.ах ну да, оно же stateful из-за index. тоже, кстати, уродство, но пусть.
но тогда почему оно говорит, какие файлы созданы/удалены, но не говорит, какие изменены? зачем дублирует commit message, которое только что передавалось юзером в ключе -m/набиралось юзером же в редакторе? что пользователь получает от того, что знает хэш только что созданного коммита? для кого вся эта информация?>> Mercurial после commit молчит. Bzr молчит. git — гадит.
> (пожимает плечами) google://git-alias, исправь. в чём проблема-то? авторы гита (и я тоже) считают, что лучше не молчать.я про алиасы был в курсе уже на третий день знакомства с git. тогда мне было пофиг. а потом я git не использовал напрямую.
>> дуршлаг без дырок
> а, я понял: ты из противников настроек в программах, всё должно быть «искаропки».я не против настроек. я против «не работает искаропки». git искаропки и без чтения манов *И* книг вроде «pro git» в поисках ответа на вопросы типа «а почему reset именно --hard? а почему reset, а не checkout?» не работает. плюс марсианская терминология, которую приходится парсить с глоссарием в соседнем окне.
inbefore «я манов не читал»: заучить 5 команд может любой идиот. а вот чтобы использовать их осознанно — приходится хотя бы читать маны. в случае с hg чтения манов достаточно для осознанного использования. в случае с git для этого приходится изучать, что происходит у него в кишках. и это — непроизводительные затраты времени, т.к. в дальнейшем они не окупаются, на мой взгляд.> небось, Lua и Scheme тоже за языки не считаешь, потому что они предоставляют механизмы, а не реализации.
вообще как-то не задумывался над вопросом «являются ли Lua и Scheme языками». видимо, таки считаю. а с чего вы взяли, что нет?
> это, в принципе, «конфликт» code monkeys и programmers. первые предпочитают, чтобы было как можно больше реализаций, а вторые — чтобы дали простые механизмы для создания своих реализаций.
ахаха. то есть меня вы, очевидно, относите, к первому типу? не стесняйтесь в оскорблениях, прошу вас — это же интернеты, да и вы пишете из-под анонимуса.
> собственно, штришок к портрету типичного пользователя hg.
можно подумать, вы их много видели. inbefore «достаточно»: сколько именно знакомых вам людей используют hg в коммерческих проектах?
как я уже говорил, vcs — *инструмент* управления версиями. использование его прямой прибыли не приносит. следовательно, лучше тот инструмент, который а) меньше мешает работать б) более предсказуем. В моём случае таковым оказался mercurial. Я исхожу из 6 месяцев git, ~года hg и опять 3 мес. использования git в оплачиваемых проектах.
>> отучайтесь переносить собственные комплексы на незнакомых людей. что, программист — уже не пользователь? и меня, мягко говоря, смущает 120 команд, из которых максимум четверть в состоянии сделать что-то полезное самостоятельно, без скармливания им в stdin сотен недокументированных данных.
> см. выше про code monkey vs programmer.
>> и я никогда. а команда есть. а зачем она юзеру?
> «дядя Петя, вы дурак?» (ц) опять code monkey vs programmer.вы точно понимаете, что вам говорят? попробую переформулировать.
конечный пользователь (*любой*) использует git upload-pack сотоварищи (2/3 команд git) чуть менее, чем никогда. зачем оно тогда болтается в автокомплите и git help? и, что важнее — где, чёрт побери, написано «дорогой новичок, в git 120 команд, 2/3 из которых — для внутреннего использования и не понадобятся тебе вообще никогда; вот их список: [список поскипан]».
>> я опираюсь на определение UNIX way Эрика Реймонда
>> А вы?
> а я — на своё. выразить можно очень просто: важны механизмы, а не реализации. имея нужные механизмы, любую желаемую реализацию можно собрать практически «из кубиков». опять code monkey vs programmer.похоже, у вас очень много свободного времени, если вы ещё и занимаетесь «собиранием реализаций». но это скорее всего пройдёт.
я не против «собирать из кубиков», отнюдь. но на дворе 2010, а не 1999. зачем «собирать» инструмент, если уже есть готовые и можно *не* собирать? олсо git уже давно не является каркасом VCS.И всё-таки: какой конкретный профит даёт любому пользователю обилие низкоуровневых команд в git?
давай будем считать, что я слил: ты просто не в состоянии, похоже, понять, почему механизмы, а не реализации, зачем это, как и куда. уровень code monkey, увы. в общем-то, ничего плохого, с этим не умирают. впрочем, и не творят.
а зачем сразу в кусты? если вы правы и понимаете, почему, то вам не должно составить труда изложить вашу точку зрения словами.
> впрочем, и не творят.А, так вы целый Творец? Чорт, я польщён. Внукам буду рассказывать, что пересекался с настоящим Творцом От Программирования.
Так это, я не пойму, почему вы уходите? Уже вроде и конкретизировал вопросы с претензиями по самое никуда, приготовился Познать Истину — и тут такое. I am disappoint.
Ладно, пойду дальше влачить своё жалкое существование.
> ах ну да, оно же stateful из-за index. тоже, кстати, уродство, но пусть./me приготовился выслушать ответ за порожний базар
[skip -- стоны пхпшника про си, типовой набор]
>> ах ну да, оно же stateful из-за index. тоже, кстати, уродство, но пусть.
> /me приготовился выслушать ответ за порожний базарконкретно этот момент я согласен списать на вкусовщину.
по остальным пунктам есть, что сказать?
> юниксвейнее — это не гадить в консоль после каждого коммита.В данном разе неудобно, а -q не отменяли.
>> юниксвейнее — это не гадить в консоль после каждого коммита.
> В данном разе неудобно, а -q не отменяли.дуршлаг без дырок
>>> юниксвейнее — это не гадить в консоль после каждого коммита.
>> В данном разе неудобно, а -q не отменяли.
> дуршлаг без дырокcode monkey cannot into aliases.
>>> юниксвейнее — это не гадить в консоль после каждого коммита.
>> В данном разе неудобно, а -q не отменяли.
> дуршлаг без дырокХорошо, давайте переформулирую: в данном случае мне тоже удобней видеть сразу нужное без лишних действий (а докопаться Вы ещё могли к покраске, которую по строго юниксвею строило бы делать каким colorifer, и автопейджеру, потому как надо бы звать руками less -SR).
Можно было бы предъявить дальнейшие контраргументы и продолжать тратить на всё это время, но дискуссия с Вами уже давно явно о вкусах, а они спора не стоят. Мне вот слакварь не нравится, ну и не ем.
>>>> юниксвейнее — это не гадить в консоль после каждого коммита.
>>> В данном разе неудобно, а -q не отменяли.
>> дуршлаг без дырок
> Хорошо, давайте переформулирую: в данном случае мне тоже удобней видеть сразу нужное без лишних действий (а докопаться Вы ещё могли к покраске, которую по строго юниксвею строило бы делать каким colorifer, и автопейджеру, потому как надо бы звать руками less -SR).ну вот в hg покраска и автопейджер почему-то и сделаны, и по умолчанию отключены (включаются в конфиге). какбэ unixway, причём даже в вашей трактовке.
А ветки в hg уже запилили?
> А ветки в hg уже запилили?аналогом git branch является hg bookmark, которые включены в ядро c версии 1.8 и поставлялись в виде плагина с версии ~1.2. если же вы про возможность кодить в анально^W огороженной уютненькой пещере, к вашим услугам есть Managed Queues (http://mercurial.selenic.com/wiki/MqExtension) и local branches (http://mercurial.selenic.com/wiki/LocalbranchExtension), также существующие с незапамятных времён.
так что да, запилили. и уже очень давно. если бы вас интересовало реальное положение вещей, вы были бы в курсе.
> если же вы про возможность кодить в анально^W огороженной уютненькой пещереИнтересно, можно ли иметь сколь-нибудь заметный опыт боевой разработки и писать такое...
Если возможность смены контекстов прикручена через гланды, то ей не пользуются. Если она составляет половину сущности инструмента, то вдруг быстро оказывается, что многие вещи делаются либо на порядок удобнее (когда приходится), либо вообще делаются (когда иначе можно было обойтись откладыванием временных патчей на полочку, чтоб не заморачиваться с отдельным бранчем).
Потому что в жизни обойтись одним контекстом долго ну никак не выходит. Даже с cvs.
>> если же вы про возможность кодить в анально^W огороженной уютненькой пещере
> Интересно, можно ли иметь сколь-нибудь заметный опыт боевой разработки и писать такое...5 лет хватит?
> Если возможность смены контекстов прикручена через гланды, то ей не пользуются.
> Если она составляет половину сущности инструмента, то вдруг быстро оказывается, что
> многие вещи делаются либо на порядок удобнее (когда приходится), либо вообще
> делаются (когда иначе можно было обойтись откладыванием временных патчей на полочку,
> чтоб не заморачиваться с отдельным бранчем).Говорите конкретнее, парсер намёков is under maintenance.
Если что, у меня текущий проект под гитом. Так вот переключать бранчи между master и develop чаще двух раз в день оказалось просто-напросто неудобно.
> Потому что в жизни обойтись одним контекстом долго ну никак не выходит.
> Даже с cvs.Поэтому, как ни странно, для активной разработки двух веток оказывается проще использовать два каталога в фс. А такую модель поддерживают чуть менее, чем все DVCS. И зачем тогда нужен git?
>проще использовать два каталога в фс
>поддерживают чуть менее, чем все DVCS. И зачем тогда нужен git?"И зачем тогда нужны все остальные DVCS?" //Obvious же fix.
<в танке>Не аргумент.</в>
>>проще использовать два каталога в фс
>>поддерживают чуть менее, чем все DVCS. И зачем тогда нужен git?
> "И зачем тогда нужны все остальные DVCS?" //Obvious же fix.остальные нужны затем, что они проще/быстрее/удобнее git
> <в танке>Не аргумент.</в>а ну хорошо
> Если что, у меня текущий проект под гитом. Так вот переключать бранчи
> между master и develop чаще двух раз в день оказалось просто-напросто
> неудобно.таки никто не рассказал про alias'ы в sh?
>> оказалось просто-напросто неудобно.
> таки никто не рассказал про alias'ы в sh?Ты ему ещё про алиасы в гите расскажи...
Ртуть работает, ртуть в крови, новость о выходе гита +v0.0.1 вызывает синдром отмены и желание поделиться ощущением неудобства со всеми... блииииин, и под вендой ниработаит нифига... Не-у-дол-но!
> Ты ему ещё про алиасы в гите расскажи...нененене, чтение манов с выражением только за деньги. %-)
>>> оказалось просто-напросто неудобно.
>> таки никто не рассказал про alias'ы в sh?
> Ты ему ещё про алиасы в гите расскажи...и про них я тоже прочитал в портянках текста, которые почему-то называют манами git
> Ртуть работает, ртуть в крови, новость о выходе гита +v0.0.1 вызывает синдром
> отмены и желание поделиться ощущением неудобства со всеми... блииииин, и под
> вендой ниработаит нифига... Не-у-дол-но!кто здесь?
>> Если что, у меня текущий проект под гитом. Так вот переключать бранчи
>> между master и develop чаще двух раз в день оказалось просто-напросто
>> неудобно.
> таки никто не рассказал про alias'ы в sh?нет, я сам прочитал. а что подвигло вас к этому выводу, позвольте поинтересоваться?
>>> если же вы про возможность кодить в анально^W огороженной уютненькой пещере
>> Интересно, можно ли иметь сколь-нибудь заметный опыт боевой разработки
>> и писать такое...
> 5 лет хватит?Не знаю. Мне с моими двадцатью такие глупости в голову почему-то не стучались.
>> Если возможность смены контекстов прикручена через гланды, то ей не пользуются.
> Говорите конкретнее, парсер намёков is under maintenance.Да вот ниже пример, спасибо.
> Если что, у меня текущий проект под гитом. Так вот переключать бранчи
> между master и develop чаще двух раз в день оказалось просто-напросто
> неудобно.Про git stash точно в курсе? :) (кажется, его тоже уже сделали наконец в hg)
>> Потому что в жизни обойтись одним контекстом долго ну никак не выходит.
> Поэтому, как ни странно, для активной разработки двух веток оказывается
> проще использовать два каталога в фс.И возвращаемся к поднятому выше вопросу про опыт. Мне вот -- ни разу не проще. Старею? :)
>>>> если же вы про возможность кодить в анально^W огороженной уютненькой пещере
>>> Интересно, можно ли иметь сколь-нибудь заметный опыт боевой разработки
>>> и писать такое...
>> 5 лет хватит?
> Не знаю. Мне с моими двадцатью такие глупости в голову почему-то не стучались.надеюсь, имеет место обычное недоразумение.
>> Если что, у меня текущий проект под гитом. Так вот переключать бранчи между master и develop чаще двух раз в день оказалось просто-напросто неудобно.
> Про git stash точно в курсе? :) (кажется, его тоже уже сделали наконец в hg)в курсе, спасибо за заботу. в hg stash был с незапамятных времён, но и вас, похоже, реальное положение вещей тоже не интересует.
>>> Потому что в жизни обойтись одним контекстом долго ну никак не выходит.
>> Поэтому, как ни странно, для активной разработки двух веток оказывается проще использовать два каталога в фс.
> И возвращаемся к поднятому выше вопросу про опыт. Мне вот -- ни разу не проще. Старею? :)нет-нет, что вы. как можно. очевидно же, что это я — дебил и неосилятор.
>>>>> возможность кодить в анально^W огороженной уютненькой пещере[...]
>> Не знаю. Мне с моими двадцатью такие глупости в голову почему-то не стучались.
> надеюсь, имеет место обычное недоразумение.Вот теперь имеет -- поясните, о чём :)
Серьёзно, переключением между контекстами в виде каталогов уже давно был сыт по горло и за такие вот "бранчи" был крайне "признателен" bzr'истам.
А в git stash не хватало как раз чтоб свежесозданное тоже упихивало, и то как раз добавили :) (хотя пока не привык к git stash pop вместо apply, порой накапливались кучки на полочке, которые потом доводилось разгребать -- надо ли иль уже ну его всё, протухло)
>> Про git stash точно в курсе? :) (кажется, его тоже уже сделали наконец в hg)
> в курсе, спасибо за заботу. в hg stash был с незапамятных времён,ЕМНИП года три-четыре, а это вполне запамятные... ну да абы работало.
> но и вас, похоже, реальное положение вещей тоже не интересует.
Если бы не интересовало, так и не упоминал бы.
PS: Вас git покусал, что ли? Или код ресетом угробили? Обычно всё-таки эмоций заслуживают люди, а не байтики.
>>>>>> возможность кодить в анально^W огороженной уютненькой пещере
> [...]
>>> Не знаю. Мне с моими двадцатью такие глупости в голову почему-то не стучались.
>> надеюсь, имеет место обычное недоразумение.
> Вот теперь имеет -- поясните, о чём :)я имел в виду, что локальные бранчи не особо и нужны. пишешь фичу? хорошо, а зачем шифроваться? ну выпинал ещё ветку, ну и что?
> Серьёзно, переключением между контекстами в виде каталогов уже давно был сыт по горло и за такие вот "бранчи" был крайне "признателен" bzr'истам.
а мне по итогу понравилось :) на текущем проекте очень удобно. пустил два сервака из разных каталогов и только успевай туда-сюда коммитить. inbefore «вы всё делаете не так»: в master вагон legacy хотфиксов, посему вот так. git flow тут избыточен.
>>> Про git stash точно в курсе? :) (кажется, его тоже уже сделали наконец в hg)
>> в курсе, спасибо за заботу. в hg stash был с незапамятных времён,
> ЕМНИП года три-четыре, а это вполне запамятные... ну да абы работало.да, извиняюсь. я, конечно же, имел в виду «hg без stash *я* не помню». есть MQ, есть два сторонних расширения.
>> но и вас, похоже, реальное положение вещей тоже не интересует.
> Если бы не интересовало, так и не упоминал бы.а ну хорошо, извините.
> PS: Вас git покусал, что ли? Или код ресетом угробили? Обычно всё-таки эмоций заслуживают люди, а не байтики.
однажды срочно-срочно пришлось менять workflow без отрыва от интенсивного кодинга. плюс я тогда только-только начал юзать git (и dvcs). как-то получилось за два дня в топку, но котяток оно того и дело убивало по поводу и без. вроде починил с помощью какой-то матери и насилия над мозгом знакомых гуров, но потом всё равно ожидал подвоха, т.к. было непонятно, почему оно работает. ощущение крайне неприятное, я вам скажу. чтение манов запутывало ситуацию ещё больше, плюс в случае проблем неясно было даже, что гуглить. нащальника, подлец, на github пересадил, а на вопросы по git только и говорил «не знаю, погугли». потом меня за эти два дня ещё и покарали слегка. было неприятно, учитывая то, что я ещё и овертаймил.
когда понадобилось слегка усовершенствовать hg workflow, я почитал про feature branches и внедрил их в течение рабочего дня. попробовал сам, поправил доку в вики, коллеги почитали, сказали «яволь» и начали юзать. ВСЁ.
>>> надеюсь, имеет место обычное недоразумение.
>> Вот теперь имеет -- поясните, о чём :)
> я имел в виду, что локальные бранчи не особо и нужны.Вам, может, и не нужны. А я ими активно пользуюсь.
> пишешь фичу? хорошо, а зачем шифроваться?
В смысле "шифроваться"? Если разработка не собирается смержиться asap в свой же master или что там за него будет, то можно пушнуть её точно так же на публику.
> ну выпинал ещё ветку, ну и что?
И то, что де-факто образовавшиеся контексты в явном виде же и разделены.
У меня вот прямо сейчас в master-бранче mkimage-profiles.git всё собирается, в другом -- подзаброшенная попытка допинать plymouth, а в текущем крушится и ломается набор шурупов, изначально рассчитывавшихся на случай сборки дистрибутивов -- переделываю на прослойку для сборки ещё и openvz template caches (возможно, там же придётся перелопатить логгинг и шире обобщить применение тегированных скриптовых хуков). Можно такие пертурбации учинять прям в master, но его тогда не пушнешь. Можно скопировать всё в сторонку, но в лесу этих сторонок я заблужусь тогда скоро и сравнивать их далеко не так удобно, как git log -p или git diff.
> а мне по итогу понравилось :) на текущем проекте очень удобно. пустил
> два сервака из разных каталогов и только успевай туда-сюда коммитить.Так хохма в том, что если я хочу именно такое устроить, то с гитом и так могу. :)
> inbefore «вы всё делаете не так»: в master вагон legacy хотфиксов, посему
> вот так. git flow тут избыточен.Ну так это по довольно-таки общепринятой логике не master ни разу, а topic branch под соответствующий старый train.
>> PS: Вас git покусал, что ли? Или код ресетом угробили? Обычно всё-таки эмоций
>> заслуживают люди, а не байтики.
> однажды срочно-срочно пришлось менять workflow без отрыва от интенсивного кодинга.Уйй, соболезную. За такое "обучение" методом швыряния в воду PM'ов надо IMHO пороть (если такой случай был).
> плюс я тогда только-только начал юзать git (и dvcs). как-то получилось за
> два дня в топку, но котяток оно того и дело убивало по поводу и без.Это всё-таки скорее издержки авральщины. Хотя конкретно перед git rebase (особенно -i) предпочитаю затарить репозиторий на случай своей же ошибки, поскольку один прецедент был (но там именно я сперва сглупил, а потом погорячился -- наработки ещё можно было вытянуть, хотя и было их не так-то много).
> вроде починил с помощью какой-то матери и насилия над мозгом знакомых гуров,
> но потом всё равно ожидал подвоха, т.к. было непонятно, почему оно работает.Вероятно, тогда погробились ссылки, но остались сами pack'и -- даже git gc штатно даёт пару недель на спохватиться). Если хотите, пороюсь в запасниках и подброшу ссылки на статьи по такому случаю.
> нащальника, подлец, на github пересадил, а на вопросы по git только и говорил
> «не знаю, погугли». потом меня за эти два дня ещё и покарали слегка. было неприятно,
> учитывая то, что я ещё и овертаймил.У-уу. За что люблю наших техдира и директора -- _они_ могут показать, как _это_ делается.
Хороший манагер понимает, что он -- бульдозер перед командой, а не крендель с кнутом и пряником. А очень хороший -- может сделать почти любую работу за тебя, но не будет. :)
> когда понадобилось слегка усовершенствовать hg workflow, я почитал про feature branches
> и внедрил их в течение рабочего дня. попробовал сам, поправил доку
> в вики, коллеги почитали, сказали «яволь» и начали юзать. ВСЁ.Аврал тоже был или вокруг поспокойней?
PS: спасибо за конструктив, намного толковей обсуждать стало. И простите, если что не так.
> Ну так это по довольно-таки общепринятой логике не master ни разу, а topic branch под соответствующий старый train.ок, спасибо за хинт
> Уйй, соболезную. За такое "обучение" методом швыряния в воду PM'ов надо IMHO пороть (если такой случай был).
тут я солидарен. можно даже бить ногами.
> У-уу. За что люблю наших техдира и директора -- _они_ могут показать, как _это_ делается.
ну вот. мне так не повезло.
> Хороший манагер понимает, что он -- бульдозер перед командой, а не крендель с кнутом и пряником. А очень хороший -- может сделать почти любую работу за тебя, но не будет. :)
да.
> Аврал тоже был или вокруг поспокойней?
немного спокойнее. но пары лишних дней не было.
так что я ещё неделю ходил под впечатлением. потому что ожидал потерять впустую минимум пару дней.> PS: спасибо за конструктив
я старался начинать с конструктивных замечаний, честно.
> И простите, если что не так.
взаимно
Итого: git для меня — источник непредвиденных рисков. Поэтому я его стараюсь не использовать. Лучше hg. Hg-git, на худой конец.
>Mercurial == Git++И это написал программист?
Тут дословно написано Mercurial тождественно равен Гиту до его увеличения.
Проверка:
Git = 1
Mercurial = Git++
print Mercurial
>1print Git
>2Не знаю, как сам Mercurial, но программисты ее используют плохие.
> Не знаю, как сам Mercurial, но программисты ее используют плохие.да ладно тебе придираться, автор их любимого языка такой же, тоже с названием накосячил.
Отлично. На самом деле сейчас git - единственная VCS.
> В "git stash" добавлена опция "--include-untracked";Вот этому очень рад
Когда под Windows уже будет стабильный GUI?
Какое ещё GUI для VCS? Для rm или cat вам GUI не хочется часом?
> Какое ещё GUI для VCS? Для rm или cat вам GUI не
> хочется часом?Да, нормальным людям необходим гуй для rm и cat, называется "файловый менеджер".
> Да, нормальным людям необходим гуй для rm и cat, называется "файловый менеджер".А потом оказывается что автоматизировать rm можно лишь посадив обезьяну нажимать кнопочки гляда на часы :)))
> Когда под Windows уже будет стабильный GUI?А чем git extensions не нравятся?
>Когда под Windows уже будет стабильный GUI?Чтобы юзать GIT на полную силу Windows не годится (как вариант - можно костылями обложить все в округе и ритуально (и с бубнами) эти костыли использовать)...но нахрена?
нет, я очень длительное время работал с git, пока не пришел к выводу что Mercurial это следующее поколение DVCS - в разы (!) проще по всем пунктам, имеет развитое GUI под все (!) ОС в виде TortoiseHG (сейчас 2.1.3), логичную архитектуру коммитов/веток/меток и всего что угодноhg подходит для командной разработки и в нем можно выделывать такие вещи, которые с git буду возможны только после длительного мучительного изучения
согласен с пользователем develop7, я, как и он, прошел такую же долгую и мучительную стадию из попыток внедрить git - просто не подходит ни по GUI ни по простоте работы
с hg я легко сделал то, о чем с git я и не мечтал разобраться, потому что с git тупо не работает - то одна особенность, то другой ньюанс, то там сложность
а в hg берешь и все работаетпока не попробуешь - НЕ ПОВЕРИШЬ
стал бы я так нахваливать hg просто так? ведь это открытый проект и никому денег за него не идет> Из вашего сообщения следует, что вы используете исключительно mercurial, с git сталкивались пару раз, и он, в виду опыта работы с hg, не понравился...
Именно так и надо было написать, я не пытаться завуалировать ваше отношение и опыт умными словами.
Да да мы поняли что вам нужен красивый Gui.
Ох уж эти "программисты мышкой"
>нет, я очень длительное время работал с git, пока не пришел к выводу что Mercurial это
>следующее поколение DVCS - в разы (!) проще по всем пунктам, имеет развитое GUI под все
>(!) ОС в виде TortoiseHG (сейчас 2.1.3), логичную архитектуру коммитов/веток/меток и
>всего что угодно
>hg подходит для ...Git подходит для всего и даже больше. А когда я был "нубом" - я юзал Windows и TortoiseGit (http://code.google.com/p/tortoisegit/ ), так как не сильно понимал философию Git и не знал "родные" тулзы Git'а (да и уровень скилла осилятора был слабоват). И, кстати, да, еще писал много букв...
Забавно что на гитхабе больше проектов чем всего программистов использующих HG, но последнии все доказывают какой он хороший и какой у него красивый гуй под виндовс(кстати полупрограчный Аэро стили поддерживает? А то, ведь, без полупрозрачных градиентов никак нельзя использовать).
А в это время BitBucket переходит на гит http://blog.bitbucket.org/2011/10/03/bitbucket-now-rocks-git...
С учетом того что гит теперь поддерживает и Google Code, похоже изделие на питоне никому отдельно не надо.
> А в это время BitBucket переходит на гит http://blog.bitbucket.org/2011/10/03/bitbucket-now-rocks-git/ну, если хайп (аналогичный хайпу вокруг nodejs) невозможно обуздать, то можно хотя бы попробовать нажиться на хомячках
>ну, если хайп (аналогичный хайпу вокруг nodejs) невозможно обуздать, то можно хотя бы попробовать нажиться на хомячках
>хайпЧто за смесь нижегородского с французским?
Есть же простое слово для описания таких вещей - "прогресс".
>>ну, если хайп (аналогичный хайпу вокруг nodejs) невозможно обуздать, то можно хотя бы попробовать нажиться на хомячках
>>хайп
> Что за смесь нижегородского с французским?
> Есть же простое слово для описания таких вещей - "прогресс".http://translate.google.com/#en|ru|hype как бэ намекаэ
Ожегов и Розенталь вам тоже намекали. Но видимо их намеки пропали даром.
> Ожегов и Розенталь вам тоже намекали. Но видимо их намеки пропали даром.а я намекал, что hype какбэ ниразу не переводится словом «прогресс».
> а я намекал, что hype какбэ ниразу не переводится словом «прогресс».Git просто удобный и быстрый и несложен в освоении. Этого достаточно для популярности у тех кто снабжен мозгом, т.е. разработчиков. Торвальдс вообще молодец, умеет сделать вещь которая потом окажется нужна толпе народа. Он не шарахается между модными трендами и супер-языками, он на результат ориентируется. Что воздается отличным результатом.
>> а я намекал, что hype какбэ ниразу не переводится словом «прогресс».
> Mercurial просто удобный и быстрый и несложен в освоении. Этого достаточно для популярности у тех кто снабжен мозгом, т.е. разработчиков.obvious fix
а вообще вы говорите так, будто вышеприведённые определения не касаются mercurial.
> А в это время BitBucket переходит на гит http://blog.bitbucket.org/2011/10/03/bitbucket-now-rocks-git...Никуда он не переходит, учимся читать.
> Никуда он не переходит, учимся читать.Тем хуже для них, имхо.