Доступен (https://www.mercurial-scm.org/wiki/Release4.8) релиз распределённой системы управления версиями Mercurial 4.8 (https://www.mercurial-scm.org/wiki/Release4.0). Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си) и распространяется под лицензией GPLv2+. Среди проектов, использующих Mercurial, можно выделить следующие: Mozilla (https://hg.mozilla.org/), OpenOffice.org, OpenSolaris, NetBeans (http://hg.netbeans.org/main), OpenJDK (http://hg.openjdk.java.net/), Nginx (http://hg.nginx.org/nginx.org), Xine (https://anonscm.debian.org/hg/xine-lib/xine-lib/) и W3C.Основные изменения (https://www.mercurial-scm.org/wiki/WhatsNew#Mercurial_4.8_.2...):
- Стабилизирована реализация шаблонов форматирования (https://www.mercurial-scm.org/wiki/GenericTemplatingPlan), которые можно применять для настройки формата вывода любых команд, в том числе для применения JSON и XML для вывода;
- Реализовано расширение "closehead" для закрытия произвольных веток без выполнения операции checkout;
- Добавлена новая настройка commands.resolve.mark-check для вывода предупреждения или ошибки при выполнении операции "--mark" при наличии конфликтующих файлов;- Добавлена новая настройка commands.resolve.confirm для подтверждения действий, выполняемых без указания имени файла;
- В команду rebase добавлен флаг "--stop" для остановки прерванных операций без отбрасывания уже перенесённых изменений;
- Предложено экспериментальное расширение absorb для "поглощения" рабочих изменений соответствующими наборами изменений;
- Добавлено экспериментальное расширение fastannotate для ускорения операций аннотирования с использованием предварительно сформированного кэша. Расширение также предоставляет дополнительные опции, такие как "--deleted";- В набор hgext добавлено расширение phabricator;
- В файл конфигурации добавлена настройка http.timeout для определения таймаута;
- Обеспечена автоматическая загрузка расширений для работы с текущим хранилищем (например, lfs);
- Расширены правила автодополнения ввода команд hg для zsh;
- Проведены оптимизации производительности.
Особенности Mercurial:- Быстродействие:
- Высокая производительность работы с хранилищем, не зависящая от числа элементом в нём (O(1) revlog);- Компактное хранение данных в проиндексированном и сжатом виде;
- Оптимизирован для эффективной работы с данными на жёстком диске;
- Все изменения и файлы в репозитории дополнительно проиндексированы;
- Для копирования данных по сети используется HTTPS и SSH, данные передаются в сжатом виде.
- Масштабирование
- Распределённая модель разработки позволяет участвовать в проекте неограниченному числу разработчиков;- Допускается произвольное слияние отдельных децентрализованных репозиториев, поддерживаемых отдельными разработчиками;
- Объём репозитория, число файлов и зафиксированных изменений не отражается отрицательно на производительности;
- При работе нет необходимости ждать освобождения блокировки.
- Надёжность.
- Для контроля целостности данных в репозитории используется SHA1 (https://www.mercurial-scm.org/wiki/mpm/SHA1) (запланирован переход на SHA256);
- Хранилище реализовано в журнальном виде - данные не замещаются, а добавляются. Ведётся журнал транзакций;
- Быстрый алгоритм проверки целостности репозитория;
- Встроенные средства резервного копирования и проверки целостности;
- Удобство использования.
- Привычный CVS-подобный набор команд;
- Наличие встроенной системы подсказки;
- Интегрированный Web-интерфейс;
- Большой выбор GUI-интерфейсов (http://www.selenic.com/mercurial/wiki/index.cgi/GUIClients).
- Лёгкость внедрения:
- Поддержка платформ UNIX, macOS и Windows;- Средства (http://www.selenic.com/mercurial/wiki/index.cgi/RepositoryCo...), упрощающие миграцию с других систем управления исходными текстами;
- Поддержка нескольких моделей организации репозитория: централизованная cvs-подобная, децентрализованная иерархическая и распределённая полуиерархическая;
- Поддержка внешних обработчиков и дополнений.
URL: https://www.mercurial-scm.org/wiki/Release4.8
Новость: https://www.opennet.dev/opennews/art.shtml?num=49558
Git наше все. Почему все еще развивается этот меркуриал? :/
Эээ, Уася! Меркуриал тебе жить мешает, да?
Мешает. Некоторые полезные проекты с неадекватным руководством почему-то выбирают его вместо стандартного git. Как результат, для работы с ними нужно учить ещё один совершенно не-юзерфрендли инструмент, их нет и не будет на стандартном же github со всеми вытекающими в виде неудобства контрибутинга и отсутствии интеграции с кучей инструментов.
Да чего там учить-то, болезный?Тем более, что локально тебе никто не мешает пользоваться git.
> Тем более, что локально тебе никто не мешает пользоваться git.Мешает, гит не умеет в поддержку иных VCS. И расширения к нему не написать.
Git ещё не умеет в версии директорий, в переименования файлов и прочая, прям CVS 21-го века какой-то. При этом, как жонглёр локальными коммитами равных себе не имеет. Собственно, для чего Торвальдс его поначалу и создавал.К несчастью, его с завидным упрямством напяливают на глобус, заставляя прикидываться универсальным инструментом. И даже с некоторым успехом.
> Git ещё не умеет в версии директорийЗачем?
> в переименования файлов
man git-mv
> Собственно, для чего Торвальдс его поначалу и создавал.
О как, оказывается.
>> Git ещё не умеет в версии директорий
> Зачем?"Не нужно"? Известный аргмент.
>> в переименования файлов
> man git-mvСам-то читал? Wrapper над mv, git remove, git add - это именно CVS.
> О как, оказывается.
Хоть для кого-то это - новость. Светоч до этого, точнее, до Bitkeeper-a, вообще патчики ручками накладывать изволили, а лог изменений вели в файлике.
Ну и самого гуру вам в помощь:
"This is a stupid (but extremely fast) directory content manager. It
doesn't do a whole lot, but what it _does_ do is track directory
contents efficiently.""Note on changesets: unlike real SCM's, changesets do not contain rename
information or file mode chane information. All of that is implicit in
the trees involved (the result tree, and the result trees of the
parents), and describing that makes no sense in this idiotic file
manager."
>>> Git ещё не умеет в версии директорий
>> Зачем?
> "Не нужно"? Известный аргмент.Так и запишем: зачем нужно - не знаю.
>>> в переименования файлов
>> man git-mv
> Сам-то читал?Все страшнее: приходилось и пользоваться.
>> О как, оказывается.
> Хоть для кого-то это - новость.Начиная с создателя...
> Так и запишем: зачем нужно - не знаю.Это из чего ж такой вывод-то? "Не нужно" - это твоя реприза. "Не знаю" - тоже пропетросянил не я. Зачем нужно, я-то как бы знаю, если же твой, вероятно, скудный опыт ничего не подсказывает, кто ж тебе доктор?
> Все страшнее: приходилось и пользоваться.
Действительно? Таки нашёл отличия от "git rm/git add"?
> Начиная с создателя...
Перелогинься, "созхдатель".
> Зачем нужно, я-то как бы знаюНо не скажешь. Знакомые "знания" двоешника...
>> Все страшнее: приходилось и пользоваться.
> Действительно? Таки нашёл отличия от "git rm/git add"?Конечно. Достаточно взглянуть на выхолоп git log --follow.
Это же угадайка обычная, результат которой ещё и от флагов зависит. Даже diff --git и то больше информации содержит :)
И ты можешь показать случай, где данная угадайка не работает?
> И ты можешь показать случай, где данная угадайка не работает?Конечно, https://github.com/openSUSE/systemd/pull/7/commits/8463b5cb4.... И нет, подобное вылезает минимум пару раз в год. И нет, переименовать одним коммитом и внести правки другим не помогает.
Thread "Just avoid holding it in that way" go
>> И ты можешь показать случай, где данная угадайка не работает?
> Конечно, https://github.com/openSUSE/systemd/pull/7/commits/8463b5cb4....А ты еще весь контент файла в этом коммите заменил бы до кучи, нафига оставлять этот жалкий огрызок?
> И нет, переименовать одним коммитом и внести правки другим не помогает.
Врешь, помогает. Просто тебе было лень. Ну или не знал, по малолетству.
>>> И ты можешь показать случай, где данная угадайка не работает?
>> Конечно, https://github.com/openSUSE/systemd/pull/7/commits/8463b5cb4....
> А ты еще весь контент файла в этом коммите заменил бы до кучи, нафига оставлять этот жалкий огрызок?Вот и оправдания начались.
>> И нет, переименовать одним коммитом и внести правки другим не помогает.
> Врешь, помогает. Просто тебе было лень. Ну или не знал, по малолетству.Только что проверил: в диффе старый файл удалило, новый создало. Enjoy ur сверхценные идеи торвольца.
> Вот и оправдания начались.Я лишь констатировал, что гранату дали обезьяне. С предсказуемым результатом.
Это не значит, что всем армиям надо выбросить современное оружие и освоить палки-копалки.
> Только что проверил: в диффе старый файл удалило, новый создало.
-->8--
$ git show
commit e792a5cf4
Author: myhand <from@hell>
Date: Thu Nov 8 11:47:29 2018 +0300Никогда не ври, дурачок.
diff --git a/rules/60-ssd-scheduler.rules b/rules/60-io-scheduler.rules
similarity index 100%
rename from rules/60-ssd-scheduler.rules
rename to rules/60-io-scheduler.rules
$ git log -2 --follow rules/60-io-scheduler.rules
commit e792a5cf4
Author: myhand <from@hell>
Date: Thu Nov 8 11:47:29 2018 +0300Никогда не ври, дурачок.
commit fc5362d2e
Author: Robert Milasan <rmilasan@suse.com>
Date: Sun Jul 27 14:20:36 2014 +0200udev: use 'deadline' IO scheduler for SSD disks
[ fixes: bnc#904517 ]
-->8--
>> Вот и оправдания начались.
> Я лишь констатировал, что гранату дали обезьяне. С предсказуемым результатом.
> Это не значит, что всем армиям надо выбросить современное оружие и освоить палки-копалки.Вот и некорректные аналогии начались.
>> Только что проверил: в диффе старый файл удалило, новый создало.
> $ git log -2 --follow rules/60-io-scheduler.rulesЯ же и говорю: в зависимости от ключей командной строки, получается то так, то этак. Когда требуется всего лишь тупо записывать за юзером, без самодеятельности. Смекаешь?
> Вот и некорректные аналогии начались.Почему? Мы же выяснили, что данным конкретным инструментом ты умеешь пользоваться не сильно лучше чем мартышка.
>>> Только что проверил: в диффе старый файл удалило, новый создало.
>> $ git log -2 --follow rules/60-io-scheduler.rules
> Я же и говорю: в зависимости от ключей командной строки, получается то так, то этак.Это, внезапно, именно то, что от разных ключей командной строки нормальные люди и ожидают.
> Когда требуется всего лишь тупо записывать за юзером,
> без самодеятельности.Да телепатии не существует, тем более что за такими "юзерами" как ты - бессмысленно записывать, ты же сам
не знаешь что сделал. Коммит объединяет переименование и изменение содержимого чуть менее чем полностью. Что это было? Ты переименовал файл и его подредактировал? Ты удалил файл и создал совершенно новый?Что записывать-то?
>> Вот и некорректные аналогии начались.
> Почему? Мы же выяснили, что данным конкретным инструментом ты умеешь пользоваться не сильно лучше чем мартышка.Как будто существует способ убедить тебя в обратном.
>>>> Только что проверил: в диффе старый файл удалило, новый создало.
>>> $ git log -2 --follow rules/60-io-scheduler.rules
>> Я же и говорю: в зависимости от ключей командной строки, получается то так, то этак.
> Это, внезапно, именно то, что от разных ключей командной строки нормальные люди и ожидают.Нормальные люди (не аутичные гики) ожидают детерминированной истории, а не различающихся показаний в зависимости от того, как к нему обратиться. Больше скажу, статистически нормальные люди смотрят диффы в вебморде, в которой нет способа подкрутить ключи git diff.
>> Когда требуется всего лишь тупо записывать за юзером,
>> без самодеятельности.
> Что это было? Ты переименовал файл и его подредактировал? Ты удалил файл и создал совершенно новый?Именно потому-то, что записывать за мной отрыжка LKML не способна (а адепты считают это фичей), такие вопросы и возникают.
> Как будто существует способ убедить тебя в обратном.Не допускать идиотских ошибок. Ну или хоть не врать для начала.
> Нормальные люди (не аутичные гики) ожидают детерминированной истории
Так она вполне детерминирована. В зависимости от того какую именно историю тебе хочется - ты именно ее и получишь, а не выхлоп генератора случайных чисел.
> статистически нормальные люди смотрят диффы в вебморде, в которой нет способа
> подкрутить ключи git diff.
>>> Когда требуется всего лишь тупо записывать за юзером,
>>> без самодеятельности.
>> Что это было? Ты переименовал файл и его подредактировал? Ты удалил файл и создал совершенно новый?
> Именно потому-то, что записывать за мной отрыжка LKML не способнаПовторяю, системы vcs - не замена отсутствующему головному мозгу. Если ты не потрудился записать именно такую историю, какую хочешь - торвальдсы тут непричем.
Хотя скажем великому и ужасному отдельное спасибо, что даже винигрет от таких погромистов, в котором намешано сразу все и еще немножко - хоть иногда инструмент позволяет рассмотреть детальнее.
> Мешает, гит не умеет в поддержку иных VCS.Как тогда я пользуюсь им, учитывая, что основные репы проектов бывают и в hg, и в svn, и даже в cvs?
> И расширения к нему не написать.
man githooks
> Как тогда я пользуюсь им, учитывая, что основные репы проектов бывают и в hg, и в svn,
> и даже в cvs?через кривые врапперы, или благодаря тому, что hg-то как раз - умеет.
А сделать посреди гитового дерева hg-subrepo - хрен там ты сможешь.
>> И расширения к нему не написать.
> man githooksанацефалы-фантики даже не понимают, чем хук отличается от расширения.
>> Как тогда я пользуюсь им, учитывая, что основные репы проектов бывают и в hg, и в svn,
>> и даже в cvs?
> через кривые врапперы, или благодаря тому, что hg-то как раз - умеет.Что hg умеет, болезный, svn?
> А сделать посреди гитового дерева hg-subrepo - хрен там ты сможешь.
Ну как бы есть задача взаимодействия с удаленным репозиторием, хранящимся в другой vcs. А не это вот все.
>>> И расширения к нему не написать.
>> man githooks
> анацефалы-фантики даже не понимают, чем хук отличается от расширения.Принципиально - ничем. Это просто модель, которая позволяет интегрировать расширения в работу репа. А вообще - расширения можно писать на чем угодно. Это у ртути API прибит к питону.
Плюс libgit.
>выбирают его вместо стандартного gitGit уже стандартизировали, я чего-то пропустил? ISO, NIST, ГОСТ?
>на стандартном же github
О, оказывается МыСы уже подало заявку на стандартизацию своего GitHub...
Это такая мода пошла, где хайп и стандарт - синонимы.
Специально, чтобы тебя позлить.
> Git наше все. Почему все еще развивается этот меркуриал? :/дык видишь же - мурзилла никак с него не слезет, им бы стильно-модно-молодежно перетечь на гитлаб, там иконочки кругленькие, а они чего-то, все никак.
Популярность Git держится на моде и известности Торвальдса. Если бы Торвальд выбрал Mercurial, ты бы сейчас в захлёб орал, что именно он ваше всё. На самом деле нет никаких принципиальных преимуществ Mercurial над Git.
популярность git держится на бабках инвесторов, вбуханных в гитляп и гитхляп. (в рот Торвальдсу смотрят нолько нубы-опесорсники, из которых после окончания института получается нормальный менеджер среднего звена, в большинстве случаев)
Поскольку первый hg поддерживает на от...сь, а второй просто никак - он непопулярен и популярен не будет.И это хорошо - меньше альтернативно-одаренных мастеров pull/push пройдет через фильтр.
На самом деле - самый лучший код пишут программирующие в наручниках. Левой ногой. По крайней мере, однажды таки напишут. Пока, наверное, обдумывают.
для программирования никакие vcs не нужны, а умеющему только pull/push и бесполезны. Они становятся нужны, когда результат этого программирования выносится с твоего локалхоста.и тут хуже "шлите ваши патчи в рассылку, порезав мелкими ломтиками" придумать что-то сложно, однако же, вот - цельный линукс написали (правда, многие ключевые части таки делали команды, умевшие пользоваться vcs, но они для себя это делали, а потом подавали на блюдечке мелкими ломтиками, как положено)
> для программирования никакие vcs не нужныВаша правда. Компьютеры, кстати, тоже. Кайло в зубы - и высекай нетленку на гранитных плитах, как ебиптяне.
> а умеющему только pull/push и бесполезны.
Странные вокруг вас люди, может у них диагноз какой. Большинству вменяемых граждан абсолютно
несложно освоить современные vcs на приемлемом пользовательском уровне.Хотя вот еще всех в школе писать учили, а пушкиными сделались почему-то не все. Подозреваю,
умение писать (а возможно и читать) вы находите для всякого быдла (кто кроме вас) - излишними...> Они становятся нужны, когда результат этого программирования выносится с твоего локалхоста.
> и тут хуже "шлите ваши патчи в рассылку, порезав мелкими ломтиками" придумать
> что-то сложно, однако же, вот - цельный линукс написали (правда, многие
> ключевые части таки делали команды, умевшие пользоваться vcsЯ вам открою страшную тайну: не только "умевшие пользоваться vcs" (т.е. обычные, вменяемые
люди), а еще и пользовавшиеся "внутре" нормальными багтрекерами, системами рецензирования
кода и т.п. "Шлите патчи в рассылку" - это только верхушка айсберга. Потому в линуксе данный
реликт времен очаковских до сих пор и работает.
> для программирования никакие vcs не нужныДа, и текстовый редактор не нужен, можно ведь делать cat >src.c ENTER, вводить код, и тыкать в Ctrl-D по окончании ввода. И компилятор не нужен, можно ведь ассемблировать вручную. Да и вообще компьютер не нужен, программировать можно в уме.
> Они становятся нужны, когда результат этого программирования выносится с твоего локалхоста.
Не. Не знаю как mercurial, а git нужен даже для проекта который ты пилишь самостоятельно для себя в одно лицо. git даёт свободу внесения изменений. Ты можешь взять и поменять что-то для теста. Ты можешь начать вносить отладочный вывод, оверпроверки, и кучу другого отладочного кода, если что-то работает непонятным образом, только для того чтобы разобраться что происходит. Когда понимание придёт, всё что надо будет сделать git checkout --hard. То есть, всё это можно и без git'а: чисто теоретически можно делать это создавая копии директорий или как-нибудь ещё, но git делает эти вещи простыми.
Если же на более сложном уровне, то git позволяет создать внятную историю изменений, и когда ты отвлёкся от своего проекта на полгода, потом вернулся к нему, ты приходишь не к куче непонятного неработающего кода, с которым надо несколько часов сидеть только чтобы разобраться что тут не работает, а что не реализовано, нет. Ты смотришь в историю, в локальные ветки, в последние коммиты, и через десять минут ты в теме, ты уже вспомнил на чём именно остановился полгода назад. Правда, чтобы это работало, неплохо было бы уже не просто эпизодически делать git commit, но тащить несколько веток, раскладывать коммиты по ним, переупорядочивая их, разбивая иногда на более мелкие или наоборот объединяя в более крупные. Впрочем, даже без этого -- беспорядочный поток коммитов вместо истории тоже очень полезен для понимания происходящего.
>> Они становятся нужны, когда результат этого программирования выносится с твоего локалхоста.
> Не. Не знаю как mercurial, а git нужен даже для проекта который[skip]
ты прекрасно описал use-pattern cvs (какое, милые, у вас, тысячелетье на дворе?)этакий "умный undelete".
только вот синтаксис git checkout --hard (да и семантика - причем бы тут - checkout?) придуман кем-то явно незнакомым с cvs и вообще vcs, и изобретал велосипед - ну и изобрел, с квадратными колесами и без цепи, надо ногами толкаться, зато так веселее.
> Если же на более сложном уровне, то git позволяет создать внятную историю
к сожалению, гит _форсирует_ подделку этой самой истории - потому что никаким другим способом даже на локалхосте работать невозможно, не говоря уже о совместной работе (ну если не считать таковым push -f - что у нас вон принято делать, но тут, традиционно, ни разработчики, ни тем более архитекторы проекта гитом пользоваться и не умеют)
поэтому никакой внятной истории не получается - если проект твой личный, гит тебе поможет вспомнить, что ты делал, наверное, и если ты сам оставлял на память точки вспоминания - ветки, теги. А если не твой - то хрена там с два, особенно, если ты не знаешь заранее ответ.
> более крупные. Впрочем, даже без этого -- беспорядочный поток коммитов вместо
> истории тоже очень полезен для понимания происходящего.говорю же - cvs, 1998й год. Нет, ветки она тоже умеет. Она не умеет rebase.
зато и синтаксис, и семантика человеческие. А если что-то пошло не так - она останавливается и ждет, пока ты сам разберешься. И 3way merge у нее, по-моему, уже тоже был - причем без использования прекрасного kdiff, который не очень здорово работает через ssh (а скоро совсем не будет, с пришествием божественного вафлянда)
А теперь, без подглядывания в шпаргалку, расскажи нам, как откатить обратно ошибочный git pull вместо fetch ? (в hg такая ошибка невозможна, потому что у нее нет "третьего состояния" git add)
банальнейшая ведь ситуация, если чуть в стороне от локалхоста :-(
>[оверквотинг удален]
> только вот синтаксис git checkout --hard (да и семантика - причем бы
> тут - checkout?) придуман кем-то явно незнакомым с cvs и вообще
> vcs, и изобретал велосипед - ну и изобрел, с квадратными колесами
> и без цепи, надо ногами толкаться, зато так веселее.
>> Если же на более сложном уровне, то git позволяет создать внятную историю
> к сожалению, гит _форсирует_ подделку этой самой истории - потому что никаким
> другим способом даже на локалхосте работать невозможно, не говоря уже о
> совместной работе (ну если не считать таковым push -f - что
> у нас вон принято делать, но тут, традиционно, ни разработчики, ни
> тем более архитекторы проекта гитом пользоваться и не умеют)Это интересно. Если тебе не влом, расскажи мне, как в "нормальных" vcs я мог бы разрулить следующую ситуацию и получить внятную историю. Смотри, я запиливаю в проект новый функционал. В процессе я нахожу косяки в проекте не связанные с тем, что я сейчас делаю -- я могу создать issues об этих косяках, но часто проще исправить на месте. Иногда я нахожу косяки связанные с тем, что я делаю -- то есть я не могу запилить новый функционал, пока не внесу некоторые архитектурные изменения в существующий проект. Тут три типа изменений, в случае с git я могу вносить их хоть в полном беспорядке, с тем чтобы позже раскидать их по веткам с говорящими именами, а потом эти ветки красиво мергнуть в dev-ветку. Как то же самое проделать без "подделки истории"? Я ведь вношу все эти изменения не зная, что будет через полчаса. У меня есть определённый план внесения изменений, но он постоянно спотыкается о реальность и меняется.
> поэтому никакой внятной истории не получается - если проект твой личный, гит
> тебе поможет вспомнить, что ты делал, наверное, и если ты сам
> оставлял на память точки вспоминания - ветки, теги. А если не
> твой - то хрена там с два, особенно, если ты не
> знаешь заранее ответ.История она не для того, чтобы отслеживать процесс разработки таким, каким он был. История она для того, чтобы зафиксировать и документировать изменения вносимые в проект. История должна отвечать на вопрос "зачем были внесены те или иные изменения".
>> более крупные. Впрочем, даже без этого -- беспорядочный поток коммитов вместо
>> истории тоже очень полезен для понимания происходящего.
> говорю же - cvs, 1998й год. Нет, ветки она тоже умеет. Она
> не умеет rebase.cvs я пробовал освоить ещё до git. Ниасилил. Совершенно ненужная вещь. Может быть для командной разработки и полезно, но для локальной разработки в одно лицо -- излишество.
> зато и синтаксис, и семантика человеческие.
Да что вы так озабочены этими человеками? vcs создаётся для программистов, а не для человеков, это тот редкий случай, когда разработку интерфейса не стоит доверять UX-специалисту, а следует оставить программисту, потому что программист для программиста сделает лучше, чем UX-спец для программиста.
> А теперь, без подглядывания в шпаргалку, расскажи нам, как откатить обратно ошибочный
> git pull вместо fetch ?В чем проблема? Как откатить назад несколько коммитов? Не заглядывая в шпаргалку, я бы предположил что надо сделать git checkout на последний правильный коммит, а затем туда перенести HEAD ветки. Последнее навскидку я не уверен как сделать. Но если без шпаргалок, то можно удалить старую ветку, и создать на этом коммите её заново. А на всякий случай, прежде чем удалять, надо... короче, чтобы было понятно, последовательность действий такая:
git branch temp
git branch -d screwed
git checkout <hash of last good commit>
git branch screwed
git branch -d tempЯ бы делал так, если бы не мог заглянуть в шпаргалку. Но я не понимаю этого искусственного ограничения: man git-branch всегда под рукой.
> (в hg такая ошибка невозможна, потому что у нее нет "третьего состояния" git add)
И как hg предлагает обходить нехватку этого третьего состояния? Оно ведь очень удобно, для создания истории в первом приближении: я собираю в коммит то, что нужно, смотрю всё ли правильно, затем делаю commit. Не совсем удобно то, что если я хочу закоммитить не все изменения в файле A, а только часть их -- приходится не на этапе git add это делать, а уже непосредственно в процессе commit'а, а в случае ошибок откатывать коммит. Но и всё же, add очень удобен. Как жить без него?
> банальнейшая ведь ситуация, если чуть в стороне от локалхоста :-(
А вот не надо спорить с самим собой. Я знаю, что это очень удобно: придумываешь такие утверждения с которыми знаешь как спорить, приписываешь эти утверждения оппоненту и споришь с ними. Лепота. Но не надо так делать. Я говорил о том, что git полезен даже при разработке на локалхосте. И могу добавить, что в отличие от cvs, которая больше путается под ногами и мешает, чем помогает.
> Не совсем удобно то, что если я хочу закоммитить не все изменения в файле A, а только часть их -- приходится не на этапе git add это делать, а уже непосредственно в процессе commit'а, а в случае ошибок откатывать коммит.Вы имеете в виду "git commit -p"? Возрадуйтесь, ибо существует и "git add -p".
> только вот синтаксис git checkout --hard (да и семантика - причем бы
> тут - checkout?)Притом, что обновление рабочего каталога.
> придуман кем-то явно незнакомым с cvs
Это с чего вдруг, гражданин телепат?
> изобретал велосипед - ну и изобрел, с квадратными колесами
Велосипед с квадратными колесами умеет делать атомарные изменения в данных репозитория, в отличие от cvs, способной превратить их в лапшу, если UPS не озаботиться. Или интернет в нужный момент кончился...
>> Если же на более сложном уровне, то git позволяет создать внятную историю
> к сожалению, гит _форсирует_ подделку этой самой историиТорвальдс сам к вам с наганом приходил, заставляя push -f?
Переписывание истории - вещь полезная локально, для чего ее и используют. Если же вас угораздило
работать с проектом, в котором кто-то постоянно push -f в центральный master - git тут не виноватый.
Вы уж тогда в корень зрите - надо срочно молотки запретить. Они ведь людей убивают.>> более крупные. Впрочем, даже без этого -- беспорядочный поток коммитов вместо
>> истории тоже очень полезен для понимания происходящего.
> говорю же - cvs, 1998й год.И где у нас cvs bisect?
> зато и синтаксис, и семантика человеческие.
Притом человечество все упрямее им не пользуется. Даже разработчики cvs давно забили на поделку.
Впрочем, человечество у нас не Дартаньяны. Дартаньян - вы.
> И 3way merge у нее, по-моему, уже тоже был - причем без использования
> прекрасного kdiffkdiff нету, 3way merge в git работает - ЧЯДНТ?
> А теперь, без подглядывания в шпаргалку, расскажи нам, как откатить обратно ошибочный
> git pull вместо fetch ? (в hg такая ошибка невозможна, потому
> что у нее нет "третьего состояния" git add)(подразумеваю, что рабочий каталог чистый от изменений, тогда)
git log -1 && git reset --hard <sha1 последнего вашего коммита>Хотя не исключаю, что можно и короче, если в шпаргалку посмотреть.
> Притом, что обновление рабочего каталога.в каком месте в слове checkout находится "обновление рабочего каталога" ?
>> придуман кем-то явно незнакомым с cvs
> Это с чего вдруг, гражданин телепат?ну вот, например, "неожиданное прочтение" слова checkout как раз об этом и говорит.
У всех, кто пользовался cvs, почему-то в этом случае - revert.> Велосипед с квадратными колесами умеет делать атомарные изменения в данных репозитория, в
> отличие от cvs, способной превратить их в лапшу, если UPS не озаботиться.у вас помимо cvs данные способна уничтожить файловая система, особенно модные-современные, героически защищающие "непротиворечивость метаданных", в ущерб данным, носитель - особенно модный-современный, секторная метка записывается вместе с сектором, каждый раз, про ssd с их 32k pages и "на кого Бог пошлет" при отказе уж молчу, а вы все без ups ?
>> к сожалению, гит _форсирует_ подделку этой самой истории
> Торвальдс сам к вам с наганом приходил, заставляя push -f?push -f это не подделка истории, это уничтожение вместе со свидетелями и создание снова (зачем устраивать армагеддец своим данным - отдельный вопрос). Подделка - rebase. Когда реальная история работы над ошибками заменяется вымышленной "для чистоты лога".
> Притом человечество все упрямее им не пользуется.
человечество прекрасненько пользуется svn, hg и даже, местами,перфорсой - хотя все они - последовательные улучшатели именно cvs. Пользоваться ей самой в наши дни - все равно что sendmail настраивать на большом релее. Можно, но непонятно, зачем.
> kdiff нету, 3way merge в git работает - ЧЯДНТ?
CONFLICT (content): Merge conflict in (какаятохрень)
в исходнике в результате какое-то
>>>>> some shit...
<<<<< more shit
ну спасибо, конечно, но 3way merge я как-то иначе представлял.
> git log -1э... он говорит - "тут какой-то automerge случился". И чего дальше? ;-) Я не хочу последствия ЭТОГО коммитить обратно в чужой репо.
ну и отдельный вопрос - что по этому поводу написано в документации. Не в гугле, а в документации ;-)> Хотя не исключаю, что можно и короче, если в шпаргалку посмотреть.
фиг там :-(
особенно с учетом что такие проляпы случаются, когда давно эту копию не трогали, и не помнят, что там было add, что просто так валялось, а что локально закоммичено но незапушено.
>> Притом, что обновление рабочего каталога.
> в каком месте в слове checkout находится "обновление рабочего каталога" ?Ну, checkout как бы символизирует check out. Дальше см. словарь англо-русский.
>>> придуман кем-то явно незнакомым с cvs
>> Это с чего вдруг, гражданин телепат?
> ну вот, например, "неожиданное прочтение" слова checkout как раз об этом и говорит.man english
> у вас помимо cvs данные способна уничтожить файловая система
Или метеорит. Но мы не про астрономию, а про конкретные баги конкретной vcs, которые
никто и никогда уже не починит. Ибо cvs - дохлая.>>> к сожалению, гит _форсирует_ подделку этой самой истории
>> Торвальдс сам к вам с наганом приходил, заставляя push -f?
> push -f это не подделка истории, это уничтожение вместе со свидетелямиКак же не подделка. Была одна история - стала другая. Прям как в РФии с ВНаУкраиной.
Более точно, конечно, push -f - это публикация поддельной истории.Однако, вы таки ушли от вопроса: злые коммисары с маузерами вас
заставляют историю подделывать? Может на свете и есть граждане,
которые каждый коммит в процессе работы обмусолят до невероятности,
прежде чем закоммитить - и список файлов, и изменения в них, и
комментарий к коммиту... Но если глянуть на публичные cvs репы - то
возникает подозрение, что подобные граждане пользуются точно не cvs.> Когда реальная история работы над ошибками заменяется вымышленной "для
> чистоты лога".Не для "чистоты лога", а для удобства последующей работы с изменениями.
> ну спасибо, конечно, но 3way merge я как-то иначе представлял.
Кто-ж виноват, что вы даже не удосужились выяснить что это такое.
>> git log -1
> э... он говорит - "тут какой-то automerge случился". И чего дальше? ;-)Смотрим sha в мерже, там будет помимо HEAD'а - sha вашего последнего коммита, который
и вставляем во вторую команду.> Я не хочу последствия ЭТОГО коммитить обратно в чужой репо.
Не хотите, не коммитьте. Вам же объяснили как быть. История с ненужным мержем просто исчезнет.
> ну и отдельный вопрос - что по этому поводу написано в документации.
Без понятия. А какая разница? Скорее всего, данную задачу можно решить еще
как-то, как и большинство задач. Может в одну команду, а не две. Только нафига
мне это выяснять?
> Ну, checkout как бы символизирует check out. Дальше см. словарь англо-русский."обновления(!) рабочего каталога" я в этом словаре не усматриваю. Наверное, у тебя гуглтранслейт вместо словаря.
> Однако, вы таки ушли от вопроса: злые коммисары с маузерами вас заставляют историю подделывать?
да, заставляют - git не оставляет другого workflow кроме бесконечных rebase.
>> ну и отдельный вопрос - что по этому поводу написано в документации.
> Без понятия. А какая разница?такая что это частая ошибка и документация, в которой этого нет в самом начале - дерьмо, а не документация.
>> Ну, checkout как бы символизирует check out. Дальше см. словарь англо-русский.
> "обновления(!) рабочего каталога" я в этом словаре не усматриваю.Смотри лучше.
>> Однако, вы таки ушли от вопроса: злые коммисары с маузерами вас заставляют историю подделывать?
> да, заставляют - git не оставляет другого workflow кроме бесконечных rebase.Делай коммиты так, чтобы потом не понадобилось их переделывать по-человечески - и не нужно будет никаких rebase. Удиви мир своим гением!
>>> ну и отдельный вопрос - что по этому поводу написано в документации.
>> Без понятия. А какая разница?
> такая что это частая ошибкаЗа последние несколько лет - на данную "частую ошибку" не натыкался ни разу. На что-то
подобное, кажется, однажды (кажется, случайно смержил очень сырую ветку в другую, уже
почти готовую в master). Ни в документацию, ни в гугл лезть при этом не понадобилось.> документация, в которой этого нет в самом начале - дерьмо, а не документация.
Документация должна объяснять как что работает, а не натаскивать пользователей как собачек
Павлова на частные случаи.
> Когда реальная история работы над ошибками заменяется вымышленной "для чистоты лога".Тут как бы очень спорный вопрос - надо ли мне видеть вообще всю лажу Пупкина. Я и сам так порой балуюсь. Особенно если хочу чтобы изменения аудит другими рожами прошли. Если я наспамлю там своими потугами в которых наломал дров - все только запутаются, а аудит как таковой не получится вообще. Народ потеряется в техническом гуано и вместо изучения моего кода будет пыриться в всякий спам. Что им даст знание что я наломал дров, передумал, попробовал еще раз и еще и иначе - я даже и не знаю. Скорее всего получится как с лениным и жандармами - задолбаются и читать окончательный вариант вообще толком не будут. А вот это совсем не айс.
> человечество прекрасненько пользуется svn, hg и даже, местами,перфорсой - хотя все они
> - последовательные улучшатели именно cvs.Так и на лошадях кто-то ездит. Просто их осталось мало.
> Тут как бы очень спорный вопрос - надо ли мне видеть вообще
> всю лажу Пупкина. Я и сам так порой балуюсь. Особенно еслив случае hg можно баловаться в named branches - которые можно вообще не экспортировать наружу, тогда ты видишь только результат мержа.
Но свою историю видишь в неизменном виде, пока она вообще тебе нужна (а дальше close ее и больше не видишь).при этом от ошибочного экспорта гит как раз нифига не защищает, выполняя ненужные автомержи, если ты не озаботился вовремя убрать с дороги свои изменения. И опять занимаемся подчисткой истории - на сей раз ради чистоты workflow.
> Так и на лошадях кто-то ездит. Просто их осталось мало.
да, но колеса-то по прежнему круглые. Квадратные только после весеннего таяния асфальта в отдельно взятой стране бывают. И их, обычно, принято сразу же менять ;-)
> И где у нас cvs bisect?До его окончания не дожил даже МакЛауд. Представляешь себе как оно - на любое действо полпроекта заново качать? С таким bisect проще будет вычислить баг по старинке. А по другому CVS не умеет, внезапно.
> говорю же - cvs, 1998й год. Нет, ветки она тоже умеет. Она
> не умеет rebase.Она не умеет, блин, локальную работу с версиями толком. Да и ремотную - перекачивает полпроекта на каждый пшик. И если в hello world с этим можно жить, то в проекте размером с хотя-бы реактос это извините полный ахтунг. Как bisect сделать - да никак, такой хайтек CVSникам недоступен, да и смысла в нем мало - во многих случаях скачать проект дюжину раз займет дольше чем баг пришлепнуть иными методами.
> для программирования никакие vcs не нужны, а умеющему только pull/push и бесполезны.Ну да. Древние как-то тумблерами на шину, с тетрадного листка. Правда вот время написания программы и исправления в ней ошибок было, скажу я вам.
>требующие высокой производительности части оформлены в виде модулей на Си… а остальное реализовано по принципу "и так сойдет".
Принцип Парето
>>требующие высокой производительности части оформлены в виде модулей на Си
> … а остальное реализовано по принципу "и так сойдет".А, ну да, это ж:
> Реализация команды "git difftool" переписана на языке Си;
> Реализации "git pull" и "git am" переписаны на языке Си (преобразованы во встроенные команды вместо ранее применяемых shell-скриптов git-pull.sh и git-am.sh);было давно (аж целых 2-3 года прошло) и поэтому уже почти неправда?
К сожалению, ртуть проиграла эту гонку и я рад, что остался только один.
Причём не самый лучший. Mercurial вроде лучше Git, а Bazaar ещё лучше, но в целом Гита достаточно и да, удобно, что только один. Ещё бы все использовали Гитхаб с его системой issue вместо своих серверов чтобы не надо было регистрироваться на каждом сраном багтрекере чтобы зарепортить баг - вообще была бы красота.
Github уже не тру, его же мелкомягкие купили. Чёрная метка поставлена.
Черная метка кому? Ну наверное не гиту - его ms даже в студии внедрил. Хоть это и анекдотично.
Майкрософт в первую очередь бизнесмены, а не какая-то технологическая компания и надо это помнить. А Вы все думаете, что они там что-то производят. В лучшем случае у Microsoft хватает мозгов купить или интегрировать успешную технологию. Я думал уже давно все догодались. Это бизнес по американский и тут нечего больше сказать. Другое дело что путь в целом в тупик.
Базар вообще донный, не даром с него все известные проекты свалили, а разработка остановлена
> Базар вообще донный, не даром с него все известные проекты свалили, а
> разработка остановлена
> https://solovyov.net/blog/2011/bzr-hate-and-hate/ну вообще-то у него достаточно странный набор претензий - далеко не всем и все они будут актуальны, попытка сохранить, покуда можно, статические номера версий, к примеру, заслуживает всяческого одобрения, как и попытка сделать их удобозапоминаемыми и читаемыми. При этом лично мне нафиг не надо диктовать кому-то версию по телефону - что это за хрень и зачем оно кому-то вообще может понадобиться, кроме мальчиков с феноменальной памятью?
а прямая работа с remote repo может и пригодиться, к примеру.
у авффтара, кстати, есть и креатифф про git vs hg: https://solovyov.net/blog/2008/mercurial-vs-git/
- он и посвежее будет, заодно. С первой его половиной соглашусь безусловно. Остальное там явно вызвано крайне эпизодичной работой с git.
> Привычный CVS-подобный набор команд;Интересно много ли осталось людей, кому он привычный. Я вот как изучил CVS ещё в школе, так и забыл, использовать никогда не приходилось, думаю сейчас привычный большинству таки Git.
> думаю сейчас привычный большинству таки Git.сейчас, как и тогда, когда вы не учились в школе, а били баклуши, "привычный большинству git" - это git pull и git push. Никакие другие команды "большинством" ниасилены, разьве что совсем продвинутые умеют еще и rebase. "зато мы умеем кликать в кнопочки на гитхабе".
А когда нужно таки управление версиями, а не pull/push и кнопочки - выясняется, что вот те, кому еще cvs привычен, примерно понимают, что нужно делать, а остальные только глазами хлоп-хлоп.
ну это и камень в огород гита. нафига сделать сложно, если можно просто?
> ну это и камень в огород гита. нафига сделать сложно, если можно просто?там скорее не сложно, а просто криво - нафига - понятно, потому что целевой пользователь - Линус с его "шлите патчи почтой, порезав мелкими ломтиками, а то у меня почтовка скролл не умеет", а все остальное вторично и уже как получилось в сложившейся архитектуре.
А целевая аудитория hg - это были люди, которым cvs уже было неудобно, а платить за bitbucket явно плохим п-сам не хотелось. Поэтому местами тоже странно, но значительно более предназначено для людей, а не роботов.
> ну это и камень в огород гита. нафига сделать сложно, если можно просто?Так Торвальдс под свой уровень и уровень своей команды делал. Но простейшие операции обучаются делать даже маркетоиды, как ни странно.
> Так Торвальдс под свой уровень и уровень своей команды делал. Но простейшиене обижайте команду - команд там было не одна, и многие ушли из проекта, так и не сумев уговорить линуса научиться пользоваться хоть какой vcs. Преуспел лишь продаван - маркетоид bitkeeper'а.
> операции обучаются делать даже маркетоиды, как ни странно.
а мы потом за ними разгребаем, за этими простейшими :-(
О, илитка подтянулась. А что для вас "управление версиями"? Неужель многоэтажные скрипты пишете используя все возможности VCS на 100%? Тогда снимаю шляпу, плюю вам в лицо и надеваю шляпу обратно. Для нормальных профпригодных людей работа с VCS не является самоцелью и заключается в тех самых полутора командах. А если VCS заставляет учить что-то ещё, то это говно в не VCS. Вот меркуриал заставляет.
> А что для вас "управление версиями"?"найди, в чужом незнакомом проекте, что именно и зачем там менялось за пару-тройку лет, и в какой момент случилась вредная хрень". Для чего еще нужны версии, интересно?
> Неужель многоэтажные скрипты пишете используя все возможности VCS на 100%?
скрипт, извлекающий из git всех потомков конкретного коммита выглядит таки да, довольно угребищно.
https://gist.github.com/kohsuke/7590246 (не мое, но в свое время очень даже пригодилось)> Для нормальных профпригодных людей
вы напрасно считаете себя профпригодным на основании того, что вас наняли лабать код. Это в свое время удавалось даже индусам, не знающим инструментов разработки.
> А если VCS заставляет учить что-то ещё, то это говно в не VCS. Вот меркуриал заставляет.
да, надо hg вместо git перед pull набирать. Какой ужас. В том, разумеется, ужас, что подобные макаки действительно пишут код, и им, скорее всего, кому-то придется пользоваться. (индус нанес значительно меньше вреда - он-то код не писал, ибо не умел)
А шо, hg научился в нормальные бранчи то уже? :)
В hg изначально нормальные бранчи, вот в git какие-то закладки.
> "найди, в чужом незнакомом проекте, что именно и зачем там менялось за пару-тройку лет, и в какой момент случилась вредная хрень"это ты про git-bisect?
> это ты про git-bisect?это про случай посложнее хеловрот, когда тест требует отдельной сложной системы, и результат его скармливать будешь вручную, потому что непонятно как еще это сделать (ну то есть все можно, вплоть до автоматизации кликанья мышью в нужные контролы, только за это время может проще заново этот проект переписать). И собирается небыстро.
>> это ты про git-bisect?
> это про случай посложнее хеловрот, когда тест требует отдельной сложной системы, и
> результат его скармливать будешь вручную, потому что непонятно как еще это
> сделать (ну то есть все можно, вплоть до автоматизации кликанья мышью
> в нужные контролы, только за это время может проще заново этот
> проект переписать). И собирается небыстро.и какие лучшие альтернативы предлагаются для решения подобных ситуаций?
> и какие лучшие альтернативы предлагаются для решения подобных ситуаций?лучшие чем что? Чем git? Или чем переписывание проекта самому, с нуля?
В истории subversion разбираться вручную таки да, много проще, как и в истории hg, особенно, если в нее не тянут привычки, намертво въевшиеся с гита, и используют ветки и мержи, а не rebase и громадные комиты возникшие из воздуха.
> В истории subversion разбираться вручную таки да, много проще, как и
> в истории hg, особенно, если в нее не тянут привычки, намертво
> въевшиеся с гита, и используют ветки и мержи, а не rebase
> и громадные комиты возникшие из воздуха.чем именно удобнее? я не знаком близко с hg, но в чем там еще разница (в контексте обсуждаемого вопроса) помимо того что коммиты помнят из какой ветки они были вмержены?
> чем именно удобнее? я не знаком близко с hg, но в чем
> там еще разница (в контексте обсуждаемого вопроса) помимо того что коммиты
> помнят из какой ветки они были вмержены?дык, мало того что они это помнят - нет rebase (ну, при правильном использовании, а не переносе вредных привычек с гита) - нет мертвых "невидимых" веток, которых как бы нет, но они вообще-то есть и у них есть своя история.
в общем, в проектах, сделанных в hg, удавалось разобраться просто методом разглядывания лога прямо в hgweb. С гитом - ни разу. совпадение, наверное.
Есть еще bazaar.
Его бы переименовать, а то для русскоязычных, может ещё на каких языках, его название производит впечатление несерьёзности.
Это отсылка к The Cathedral and the Bazaar.
Когда-то использовали в фирме базар. Есть у него свои фичи, которых нет ни в hg, ни в git. Например, очень нравилось, что с удалёнными репозиториями можно работать точно так же, как с локальными. Например, bzr log https//... или bzr merge https://.... Те же пулреквесты рассматривать гораздо удобнее. Сейчас в гите очень не хватает.
>>Реализовано расширение "closehead" для закрытия произвольных веток без выполнения операции checkout;Наконецто. Необходимость делать checkout полугодовой ветки с кучей изменений только для того, чтобы закрыть её.
Что значит закрыть ветку? Удалить ее что-ли?
Ветку удалить нельзя.
>>mark a branch as closed, hiding it from the branch list.Ветку закрывают чтобы не мешала.
а *зачем* ее закрывать? Вот она у вас спала себе спокойно в гробике, пол-года, уже мумифицировалась, вас это ведь совсем не беспокоило?нет, для наведения порядка в большом запущенном репозитории полезно, конечно, но никаких "наконец-то" - скорее "ну ок, можно теперь не чекаутить, и хрен с ним" - потому что эта процедура в любом случае грязная, долгая и малоприятная, чекаутом больше, чекаутом меньше...
я вот, скорее всего, в нужный момент не вспомню, или поленюсь уточнять синтаксис и проверять что тут именно правильная версия.
>>а *зачем* ее закрывать? Вот она у вас спала себе спокойно в гробике, пол-года, уже мумифицировалась, вас это ведь совсем не беспокоило?
>>нет, для наведения порядка в большом запущенном репозитории полезноКогда у вас большая команда и большое количество веток - определить их активность тяжело. И закрывают не закрытыте по ошибек ветки обычно после релиза или когда список открытых веток в вашей любой IDE или в CLI становится неприемлимым.
При 50+ активных разработчиков это случается буквально через пару месяцев и делать чек-аут 5-10 раз - дикая трата времени.
а, понял, вот что значит не уметь современные ide.мне-то без разницы - открытая ветка или закрытая - я работаю в своих, их я помню, и знаю еще о трех чужих, в которые иногда заглядываю. А все остальные и не вижу и не хочу. А если их попытаться в интуитивно-приятном гуе нарисовать, то да, опаньки, и бегом побежишь закрывать все что понаплодилось за неделю (тем более что пришедшие с гита разработчики плодят ветки по чем зря, переучить их не использовать ветки вместо букмарок, вероятно, невозможно).
Это не для Вас команда, а для релиз-менеджера.Ну, того человека, который, согласовав список фич/багфиксов некоторого релиза, мержит нужные фичебранчи в выбранную релизную ветку, а потом (иногда — сразу после, а иногда — сильно потом, зависит от состояния фичебранча) подчищает ставшие ненужными фичебранчи.
Так что функциональность — вполне полезная, наш релиз-менеджер (он же проджект-менеджер в нашем случае) как раз этим периодически занимается.
На третий питон еще не переехали?
какой именно из трех? ;-)нет. вот поэтому и не переехали.
К тому же в этом проекте трапы и альтернативно-одаренные плохо приживаются, поэтому версия с политкорректной заменой master/slave им тоже без надобности.
Третьи обратно совместимы внутри третьей. Так что перейти с 3.i на 3.(i+1) не проблема.
Неправда, стабилизировалась 3 ветка только с версии 3.3.
Стабилизировалась и обртная совместимость, как бы, не одно и тоже. Что, в 3.3 выкинули из языка какие-то конструкции, которые были в 3.0 - 3.2?
> Стабилизировалась и обртная совместимость, как бы, не одно и тоже. Что, в
> 3.3 выкинули из языка какие-то конструкции, которые были в 3.0 -
> 3.2?Между версиями 2.7 и 3.* много разниц, "многоплатформенный" код уже не сделать. То есть не функциональность пишешь, а смотришь как же теперь всё перевывернули, да ещё и не раз (3.4).
Пример такого кода -- питон-макросы и расширения, работающие на разных выпусках openoffice/libreoffice.
> Между версиями 2.7 и 3.* много разниц, "многоплатформенный" код уже не сделать.Ты не поверишь. Не только можно, но и делают.
> Пример такого кода -- питон-макросы и расширения, работающие на разных выпусках openoffice/libreoffice.
Примеров говнокода - много, я знаю.
>> Между версиями 2.7 и 3.* много разниц, "многоплатформенный" код уже не сделать.
> Ты не поверишь. Не только можно, но и делают.Мало ли чего на свете делают.
>> Пример такого кода -- питон-макросы и расширения, работающие на разных выпусках openoffice/libreoffice.
> Примеров говнокода - много, я знаю.Ну наконец-то хоть один специалист по говну!
Ну, а у меня должны работать мои собственные программы, вот эти самые макросы/добавки, и делаться должна (с их помощью) моя собственная работа, а не тратить постоянно время и силы на обслуживание очередных выдумок питоновых творцов. Прикладные задачи, а не обсессивно-компульсивные действия.
>>> Между версиями 2.7 и 3.* много разниц, "многоплатформенный" код уже не сделать.
>> Ты не поверишь. Не только можно, но и делают.
> Мало ли чего на свете делают.Т.е. ты просто громко пУкнул в обществе, верно?
> Ну, а у меня должны работать мои собственные программы, вот эти самые
> макросы/добавкиДа мне ж не жалко. Найми консультантов, пусть научат питону тебя и/или еще каких
разработчиков твоих макросов - и все тебе будет. Неужели русский язык виноват в том,
что ты безграмотен?
>>>> Между версиями 2.7 и 3.* много разниц, "многоплатформенный" код уже не сделать.
>>> Ты не поверишь. Не только можно, но и делают.
>> Мало ли чего на свете делают.
> Т.е. ты просто громко пУкнул в обществе, верно?Неверно. (И у тебя какая-то фиксация на этом отверстии и его функциях.)
>> Ну, а у меня должны работать мои собственные программы, вот эти самые
>> макросы/добавки
> Да мне ж не жалко. Найми консультантов, пусть научат питону тебяСовет былинной простоты. Однако всё ещё проще -- не включать в тех. процесс изделия не вполне адекватных творцов.
>> Т.е. ты просто громко пУкнул в обществе, верно?
> Неверно.В смысле? Проекты, которые умудряются поддерживать несколько версий
питона, в частности и 2.7 - немерянное количество, например все проекты
scipy.org. Но ты упрямо будешь продолжать утверждать, что Луна
таки сделана из сыра?!
>>> Ну, а у меня должны работать мои собственные программы, вот эти самые
>>> макросы/добавки
>> Да мне ж не жалко. Найми консультантов, пусть научат питону тебя
> Совет былинной простоты.Да, если ты языка не знаешь - виноваты жидорептилоиды.
> Однако всё ещё проще -- не включать в тех.
> процесс изделия не вполне адекватных творцов.Да не использую я твоих макросов, вместе с говноофисом, успокойся.
> В смысле? Проекты, которые умудряются поддерживать несколько версий
> питона, в частности и 2.7 - немерянное количество, например все проекты
> scipy.org.Примерно та же логика оправдания странных действий, что и в случае Файрфокса и слома его дополнений. Одна только переделка print чего стоит.
Ну, и выдающее суть словечко. А подумай, вот *зачем* они *должны* были "умудряться"?? И что теперь с качеством SciPy (особо -- с надёжностью)?
Прохожу молчанием остальное -- кругозор и воспитанность типичного отечественного "специалиста по ай-тии".
>> В смысле? Проекты, которые умудряются поддерживать несколько версий
>> питона, в частности и 2.7 - немерянное количество, например все проекты
>> scipy.org.
> Примерно та же логика оправдания странных действий, что и в случае Файрфокса
> и слома его дополнений. Одна только переделка print чего стоит.Где я писал про оправдания странных действий? Просто привел конкретные
примеры проектов, которых не затрудняет поддержка нескольких версий.
Раз уж тебя на pypi забанили за глупость.Просто это не макросы для охвиса, написанные криворуким школием, вот в чем штука.
> Ну, и выдающее суть словечко. А подумай, вот *зачем* они *должны* были
> "умудряться"??Это к тебе вопрос, дурачок. Ты видишь в поддержке нескольких версий что-то невозможное,
не я. Отсюда и эпитет. Филологический экскурс заканчиваем?> И что теперь с качеством SciPy (особо -- с надёжностью)?
Все хорошо, а что? Де-факто - стандарт научных вычислений в мире FOSS.
>>> В смысле? Проекты, которые умудряются поддерживать несколько версий
>>> питона, в частности и 2.7 - немерянное количество, например все проекты
>>> scipy.org.
>> Примерно та же логика оправдания странных действий, что и в случае Файрфокса
>> и слома его дополнений. Одна только переделка print чего стоит.
> Где я писал про оправдания странных действий? Просто привел конкретныеЗато я писал. Имею же я право расширить ответ сравнением?
> Раз уж тебя на pypi забанили за глупость.
> Просто это не макросы для охвиса, написанные криворуким школием, вот в чем
> Это к тебе вопрос, дурачок. Ты видишь в поддержке нескольких версийПопрыгай ещё.
> Все хорошо, а что? Де-факто - стандарт научных вычислений в мире
> FOSS.Только научным вычислениям об этом сказать забыли. Ах, в мире FOSS...
> Зато я писал. Имею же я право расширить ответ сравнением?Ты имеешь право на демагогию, да. Ну а что еще тебе остается?
>> Все хорошо, а что? Де-факто - стандарт научных вычислений в мире FOSS.
> Только научным вычислениям об этом сказать забыли.Не переживай, не забыли.
> Ты имеешь право на демагогию, да.в настоящее время каждый имеет право
вот ты же ведёшь себя в обычном вроде бы разговоре, как манки?
на этом фоне моя якобы демагогия это так, сиреневый туман>>> Все хорошо, а что? Де-факто - стандарт научных вычислений в мире FOSS.
>> Только научным вычислениям об этом сказать забыли.
> Не переживай, не забыли.и куда они вас послали?
> и куда они вас послали?Тебя - далеко и надолго.
> Неправда, стабилизировалась 3 ветка только с версии 3.3.Стабильность у нее только в одном - что апгрейдер убунты на этом стабильно лажает каждую версию с жуткими стэктрейсами. Или просто не может найти апдейт. Это эталон питонософта и его стабильного состояния пластилинового макета программы.
> Это эталон питонософтаС чего вдруг, кто назначил?
> С чего вдруг, кто назначил?Я. Очень хорошо отражает всю суть. Полный пофиг на глупости типа кодов ошибок. Новая версия не находится потому что там ошибка была, но об этом мы никогда не узнаем. Разве что strace олдскульно вбахать. Глазами читать десятки кило рапидного гуано - увольте.
Ну а трехэтажный стэктрейс обычно от того что оно само же себе версию питона апгрейднуло а потом само же на новой версии питона и облажалось. На удивление стабильный антипаттерн пиления под собой веток - за столько лет наверное можно было бы уже и усвоить про "совместимость" версий питона. И я бы понял если б это было исключение, но остальной питонософт был очень в духе.
А, еще каждый програмер на питоне мамой клянется что оно lightweight, нитармазит, O(1) и вообще. Правда толку с этого, мягко говоря. А то что кто-то на вообще совсем другом ЯП модули написал... эээ... круто наверное учить 2 совсем разных синтаксиса, для костылирования нитармазита.
>> С чего вдруг, кто назначил?
> Я.Фу, пронесло. Я уж думал, кто-то с интеллектом круче чем у морковки.
> какой именно из трех? ;-)Потому-то справедлива мысль, что не бывает по-настоящему плохих (неправильно спроектированных) ЯП, а бывают негодные юзеры.
Впрочем, пихтон именно что плохо спроектирован, что доставляет отдельно при виде толпищ его фанатов. :)
> Впрочем, пихтон именно что плохо спроектирован, что доставляет отдельно при виде толпищ
> его фанатов. :)Ну как бы если ЯП приходится патчить столько раз, руша совместимость - тут с проектированием все понятно вроде.
Спроектированные языки - все дохлые.Любые современные языки - так или иначе меняются и эволюционируют. В частности, и удаляя устаревшие вещи из библиотек и/или устаревшие языковые конструкции. C, кстати, не исключение.
> C, кстати, не исключение.Как угодно но древний лемпелзив на C89 собирается распоследним gcc. А пихтону до такого как раком до китая, на нем большинство софта через пару лет захочешь не запустишь.
>> C, кстати, не исключение.
> Как угодно но древний лемпелзив на C89 собирается распоследним gcc.Это потому, дурачок, что компиляторы поддерживают несколько стандартов. Ну и не собирал
ты что-то действительно древнее и действительно сложное. Иначе знал бы, что "есть нюансы"...> А пихтону до такого как раком до китая
Ты прикинь, скрипты, написанные для CPython 2.1 - выполняются на интерпретаторе
версии 2.1. Во чудеса!
Если бы Гвидо думал головой много лет назад, когда его, с позволения сказать, проектировал, а не «дерну идейку оттуда, ещё идейку отсюда, по идейке отовсюду», то мог бы получиться и хороший язык. Но Гвидо был молод, горяч и неопытен. Приходится поклонникам продукта жёстко кроить и перестраивать его уже в процессе использования, ага.
И сколько языков спроектировал ты?
> И сколько языков спроектировал ты?а вот и типовая подмена понятий.
"не нужно быть шеф-поваром со столетним стажем, чтобы отличить дерьмо от конфеты".
Поправил:а вот и типовая подмена понятий:
"не нужно быть шеф-поваром со столетним стажем, чтобы отличить дерьмо от конфеты".
Не благодари.
> И сколько языков спроектировал ты?Сперва добейся, ага.
Попробуй вести споры по-мужски, а не как баба. Иначе с тобой не о чем вести разговор.
Ушол в слезах.
Ты помнишь, как ты недавно с унылым prokokokoudine на своей шкуре это всё испытывал? Или тебе напомнить? Ты ж вроде не маленький, судя по мелькающим познаниям. А некоторых вещей почему-то не знаешь. Усвой, чувак, простую житейскую истину: как только в споре включается Ad Hominem ( en.wikipedia.org/wiki/Ad_hominem ), в оффлайне среди мужчин зачастую принято давать в репу (не ту, что с исходниками, а ту, что вклеена фотокарточкой в твой паспорт). А раз в интернетах все кагбе равны, то можно вести себя по-хамски? Когда ты с предмета дискуссии переходишь на личность своего оппонента, нормальная дискуссия прекращается.
> Ты ж вроде не маленький, судя по
> мелькающим познаниям. А некоторых вещей почему-то не знаешь.Это thintelligence, увы.
> Когда ты с предмета дискуссии переходишь на личность своего оппонентаКто-же тебя заставлял это делать? Неужели я тут ковырялся в носу, заявляя какой Гвидо плохой дизайнер языков?
>> Когда ты с предмета дискуссии переходишь на личность своего оппонента
> Кто-же тебя заставлял это делать? Неужели я тут ковырялся в носу,
> заявляя какой Гвидо плохой дизайнер языков?А ты Гвидо? Или он тебя нанял защищать свои интересы на опеннете? Если нет, то помалкивай.
Ты даже после моего пояснения оказался не в состоянии понять проблему. Значит я тебя переоценил по части интеллекта.
> Или он тебя нанял защищать свои интересы на опеннете? Если
> нет, то помалкивай.И что, мне каждую табуретку в интернетах сразу слушаться, которая обделается и велит мне
помалкивать, когда я пальцем на это тычу?
> Ты даже после моего пояснения оказался не в состоянии понять проблему. Значит
> я тебя переоценил по части интеллекта.Ну старина, ну thintelligence же. )))) За поясом (предположим) три с половиной до абсолюта освоенных технических средства. Где тут общее (интеллектуальное) развитие, где личностное развитие не на уровне подростка? Человек не понимает даже, что есть какая-то проблема.
В интернете мы представлены довольно скупо, можно и ошибиться. :)
Мы - это кто?
> К тому же в этом проекте трапы и альтернативно-одаренные плохо приживаются, поэтому версия с политкорректной заменой master/slave им тоже без надобности.Уже только за это стоит пользоваться этим проектом.
> К тому же в этом проекте трапы и альтернативно-одаренные плохо приживаются, поэтому
> версия с политкорректной заменой master/slave им тоже без надобности.А на питоне кто-то еще програмит?! Да быть того не может. Хотя самые отъявленные ruby конечно предпочитают.
Они всё ещё используют устаревший Python 2.7?
Да, они всё ещё используют быструю ветку питона.
И что они будут быстро предпринимать после истечение срока поддержки 2.7?
> И что они будут быстро предпринимать после истечение срока поддержки 2.7?Если доживут, то ничего
Корректность, потом скорость. Не наоборот.
Что и где корректно в трёх наиболее распространённых ветках третьепитона (3.3, 3.5, 3.6)?
Mercurial? покойся с миром!
Ага...
- А что ты умеешь?
- Могу хоронить...
- А еще что?
- Могу и не хоронить.
Давно уже переписали с богомерзкого Си https://github.com/facebookexperimental/mononoke
> Давно уже переписали с богомерзкого Си https://github.com/facebookexperimental/mononoke"The version that we provide on GitHub does not build yet." Ну ок.
все норм - они переписали, и у них и для них работает (как-то) - а то что выложили на гитшлак - "нате подавитесь, мы так поддерживаем опенсорс" - ну да, даже и не собирается.А чего вы хотите от тyпых и жадных?
потом в нем начнутся remote code exec from rogue repository и много других забавных вещей.
к счастью, в реальной жизни нафиг не надо, а если ты работаешь на мордокнигу - сам виноват.
Покайся, святотатник, и больше никогда не гони на православный С!
> Покайся, святотатник, и больше никогда не гони на православный С!Пусть себе операционку с него хотя-бы перепишет, а потом быкует.
Оно всё ещё на Python 2, лол?
Вам пользоваться или чтобы новомодно было?
> Для контроля целостности данных в репозитории используется SHA1 (запланирован переход на SHA256)А что так приспичили -- или SHA1 уже ломается с писюка домохозяйки Клавы?
КГБ СССР бы знало.
Полностью ещё не ломается. Но какие-то уязвимости, пусть и далёкие от широкого практического применения, уже имеются.
Разве в OOO работает меркуриал? Достаю их исходники ч/з svn.
> Разве в OOO работает меркуриал? Достаю их исходники ч/з svn.OOO как бы по сути сдох и на этом фоне уже и не важно на чем он работает.
>Код Mercurial написан на языке PythonТак вот почему он не взлетел!
А ответ один: язык-прототип, язык-псевдокод, язык-gil. Ничего другого с такими инструментами получиться просто не могло. Зато теперь питуч 2 мёртв, и автоматически сабж вместе с ним. Отмучались блаженные.
сконвертировать в питон 3 довольно просто
> сконвертировать в питон 3 довольно простоТолько потом не работает нифига и падает с жуткими стэктрейсами. И придется перепахивать половину кода. Рефакторинг - ваше все.
> Зато теперь питуч 2 мёртв, и автоматически
> сабж вместе с ним. Отмучались блаженные."а мужики-то и не знают" ;-)
Комменты не читал. Там ожидаемо будет срач Mercurial vs Git.
Это как срач между тупоконечниками и остроконечниками.
По мне так, ситемы контроля версий - довольно примитивные штуки и разницы нет каким молотком гвозди забивать.
> Комменты не читал. Там ожидаемо будет срач Mercurial vs Git.
> Это как срач между тупоконечниками и остроконечниками.
> По мне так, ситемы контроля версий - довольно примитивные штуки и разницы
> нет каким молотком гвозди забивать.шурупы, к сожалению.
А так да, разницы никакой, пока ты не пытаешься такой кем-то забитый шуруп выкрутить. Вот тут разница между отверткой и гвоздодером становится довольно очевидна.Но в большинстве случаев - действительно, все равно.
> А так да, разницы никакой, пока ты не пытаешься такой кем-то забитый шуруп выкрутить. > Вот тут разница между отверткой и гвоздодером становится довольно очевидна.Аналогия хромает. Пр приведенному выше примеру мы должны сделать глючный коммит с помощью Git, а потом пытаться его откатить другим инструментом (Merkurial). Не получилось, значит Merkurial отстой :)
Нет, если мы гвоздь криво забили молотком, то с другой стороны молотка гвоздодер. Им же и вытащим.
Если шуруповертом криво закрутили шуруп, то им же и откручиваем.А чем конструкцию крепить, гвоздями или шурупами - это как бригадир скажет. Начальству виднее с чем лучше работать :)
>> А так да, разницы никакой, пока ты не пытаешься такой кем-то забитый шуруп выкрутить.
>> Вот тут разница между отверткой и гвоздодером становится довольно очевидна.
> Аналогия хромает.вы неправильно поняли аналогию.
> Нет, если мы гвоздь криво забили молотком, то с другой стороны молотка
> гвоздодер. Им же и вытащим.не, мы им шуруп забили, можно, конечно, попытаться вытащить, но скорее всего детальки необратимо испортятся в процессе, и в любом случае это не будет просто.
> А чем конструкцию крепить, гвоздями или шурупами - это как бригадир скажет.
> Начальству виднее с чем лучше работать :)мой типовой вопрос в этом случае - "ребята, а вы _меня_ зачем нанимали? Если вам не нужен мой опыт и знания, а есть только ваше мнение и неправильное - ну ок, расходимся, падаван вместо архитектора вам и дешевле б вышел."
но в целом вслух я его не задавал никогда - такие отсеиваются на этапе интервью, зачем на них, действительно, работать- они ж не только выберут за тебя инструменты, они и есть за тебя будут. А ты будешь месить дрова и рубить тесто.
другое дело когда бригада чужая, а тебе приходится как-то стыковаться с их работой. А там то концы гвоздей торчат из полировки, то разъемное по задумке соединение сделано на шурупах, с энтузиазмом забитых молотком (тот самый push -f).
> мой типовой вопрос в этом случае - "ребята, а вы _меня_ зачем
> нанимали? Если вам не нужен мой опыт и знания, а есть
> только ваше мнение и неправильное - ну ок, расходимся, падаван вместо
> архитектора вам и дешевле б вышел."Чтобы нанять поха в качестве архитектора - надо #$%нуться на отличненько. Вы скажите еще что за фирма так делает? Чтоб не вляпаться в таких талантов от менеджмента ненароком.
> шурупы, к сожалению."Шуруп забитый молотком держится крепче, чем гвоздь закрученный отверткой" (c). И глядя на порнографию с питоном, мимикрией под CVS и проч - это таки именно закручивание гвоздей отверткой.