Я так понял, что собственно ветки нужны для долгоживущих вещей вроде release-2.7, current-development, …, а закладки — для feature branches, чтобы исчезнуть после слияния. Во всяком случае, это кажется логичным.
С каких это пор «command-line interface» перестал быть «user interface»? Спрашивали же не «graphical user interface» (aka GUI). Хотя претензии мне здесь не совсем понятны: CLI, конечно, местами нелогичен, но не настолько, чтобы это было проблемой. Если бы была нормальная документация конечно.
А «внутренности наружу» — скорее всего имеются ввиду огромное число команд вроде «git unpack-file», предназначенных исключительно для использования их в скриптах.
Нет. У git нет API, позволяющего нормальную интеграцию с чем‐либо (делать каждый раз fork-exec и читать выхлоп из pipe — это очень медленно, как в смысле скорости разработки так и скорости исполнения. Даже несмотря на то, что интеграция пишется на языке, который успешно прячет fork-exec).
У git нет огромного количества хуков (например, preoutgoing, все pre-{command}, …).
У git нелогичное распределение функциональность по командам: checkout создаёт ветки или обновляет дерево, push отправляет изменения или удаляет их на том конце, diff может показывать изменения между ревизиями, а может — status, причём сам status этого не умеет…
У git иногда плохая обработка аргументов командной строки (pull принимает сначала аргументы для merge, затем для fetch).
У git плохая документация — она настолько подробна, что отыскать нужное зачастую не представляется возможным. Вместе с неочевидным распределением функциональности по командам это создаёт проблемы.
Аналог revsets у git обладает куда как меньшими возможностями.
Многие команды git, показывающие список ревизий, не имеют возможности настройки формата вывода.
У часто используемых команд вроде push/pull есть ненужные обязательные аргументы: «git push origin :branch».
У git нет аналога «hg incoming».
У git нет удобного аналога «hg grep».
Большую часть претензий можно игнорировать или терпеть. Но не первые две.
Описание изменения и его родители используются для вычисления хэша что в git, что в mercurial. Соответственно изменить сообщение, не «запоров» историю (точнее, не пересчитав хэши всех потомков) невозможно.
Для всех знаков клавиатуры может и не хватить. Я всё набираю в Vim со своим собственным дополнением, занимающимся транслитерацией (бонус: не надо учить слепой метод для двух раскладок). Поэтому вы видите у меня дефисы (а не дефисоминусы), минусы (если я не забываю), тирэ с неразрывным пробелом, малые пробелы между цифрами (1 000), русские кавычки и я могу набирать вещи вроде «│» не залезая в таблицу символов, а просто помня установленные мною правила. Последнее раскладкой так просто не исправляется (знаков рисования юникодных таблиц слишком много).
И почти ничего из этого в моих текстах на английском, кроме кавычек (разумеется, не русских, но и не «"»).
Fork root (fork автоматически ассоциируется с процессом, а не со специальным пользователем)
New similar terminal (многословно, но из всех вариантов — этот единственный, который я воспринимаю как надо; «Duplicate root» понятностью тоже не страдает)
Почему этот тест при нажатии куда‐либо предлагает послать E-mail info@intershop.it? Вообще абсолютно куда угодно (opera). А на chromium — открывает новое окно при нажатии «Next» или на пустом пространстве, причём (в отличие от opera), в оригинальных окне и вкладке следующий вопрос не работает (не отображаются картинки).
— The _hypot function calculates the length of the hypotenuse of a right triangle, given the length of the two sides x and y (in other words, the square root of x^2 + y^2).
— Треугольник это термин. Треугольник это геометрическая фигура, образованная тремя отрезками, которые соединяют три не лежащие на одной прямой точки. Из этого определение следует, что нет ситуации, когда у треугольника хотя бы одна сторона имеет нулевую длину, а когда такая ситуация наступает, то треугольник перестает быть таковым, даже сам смысл термина гипотенуза в таком случае теряется.
У меня в man hypot написано прямо в заголовке: «hypot, hypotf, hypotl - Euclidean distance function». И ниже:
The hypot() function returns sqrt(x*x+y*y). This is the length of the hypotenuse of a right-angled triangle with sides of length x and y, or the distance of the point (x,y) from the origin.
В стандарте (POSIX) написано точно тоже самое. Так что ваша функция обязана отрабатывать ноль правильно.
Только в man это продублировали в описании, а в стандарте написано
hypot, hypotf, hypotl — Euclidean distance function
и
These functions shall compute the value of the square root of x²+y² without undue overflow or underflow.
, но ниже только
Upon successful completion, these functions shall return the length of the hypotenuse of a right-angled triangle with sides of length x and y.
Видно, что раньше вы посылки не отправляли. У них специальный фирменный бело‐синий (жёлтый для 1‐го класса) скотч с надписями (по крайней мере «почта россии») и, вроде, логотипом (но не у скотча для первого класса — там просто надпись, что это первый класс).
Правда про первый класс не знаю — заматывают ли они им всю посылку или только часть и заматывают ли вообще. Посылки первым классом я не отправлял. Для писем первого класса вместо скотча может быть штампик.
Прикольно. Кроме konsole полной (и вообще какой‐либо) поддержки 24‐битного цвета нет просто ни у кого из терминалов, имеющих хотя бы одну стабильную версию (rxvt-unicode, aterm, eterm, evilvte, mlterm, mrxvt, sakura, xvt, xfce4-terminal, valaterm, rxvt, roxterm, kterm, gnome-terminal).
Лучше mercurial и bitbucket. На него легче перебираться с svn. Хотя главное здесь не то — на googlecode неудобно вести совместную разработку: bug tracker куда как хуже конкурентов, даже bug tracker’а github; нет pull request’ов (впрочем с svn они невозможны); нет многих возможностей вроде annotate, автоматического создания архивов с исходниками (если человеку неохота ставить subversion), показа изменений бок о бок, и т.д.
Описание есть здесь, искать «Character Attributes (SGR)», последний абзац. Кстати, у меня наверху опечатка: должно быть «38 вместо 48», конечно.
Там написано, что это ISO-8613-3. И ещё там написано, что xterm не поддерживает 24‐битный цвет, вместо этого используя ближайший из 256‐цветной палитры (что интересно — человек, давший эту ссылку также пропустил сей факт). Эксперимент показал, что это утверждение верно, но konsole при той же последовательности выдаёт реальный 24‐битный цвет, а не приближение. Теперь мне надо искать какой‐то ещё терминал. Сейчас установлю ещё 13 терминалов и потом скажу, кто ещё поддерживает 24‐битный цвет.
Интересно, а xterm 24-bit color будет? Xterm позволяет указывать 24‐битный цвет в виде последовательностей \e[48;2;{R};{G};{B}m (фон, цвет текста — 48 вместо 38) (все цифры — десятичные, от нуля до 255).
Я сейчас пилю vim для поддержки 24‐битного цвета и хотелось бы видеть эти цвета в качестве фактического стандарта. Известно, что, по крайней мере, konsole также поддерживает эти цвета.
А как проверялось с import calendar каждый раз (и зачем вообще оно проверялось)? Просто Python кэширует модули и последующие подключения производятся из словаря. С reload(calendar) (python 2)/from imp import reload; reload(calendar) картина будет совсем другой, хотя что именно следует использовать зависит от того, зачем это вообще проверялось, может надо до кучи ещё и зависимости перезагружать.
Кстати, сам модуль использует year % 4 == 0 and (year % 100 != 0 or year % 400 == 0).
При чём тут поиск? Когда вы нажимаете c<C-p> с этими настройками вы получаете что‐то вроде cat file | grep …: то есть, строку, начинающуюся на c из истории. cуже набрана. Также вы получаете не строку, содержащую c. И не строку, совпадающую с шаблоном. И не что‐то ещё.
Кроме того, в каком терминале у вас работает <C-S-r>? Терминалы вообще обычно посылают одну и ту же последовательность и для того, и для другого.
Разве <C-r> — не поиск по‐умолчанию? А как работает <C-S-r> я вообще не представляю: в xterm это то же, что и <C-r> (во всяком случае, с настройками по‐умолчанию). В urxvt тоже. В konsole (yakuake) это вообще клавиатурное сочетание, закрывающее вкладку (правда, не факт, что стандартное).
В таких случаях отправляют текст в какой‐нибудь pastebin. Ни в коем случае не делают снимок MessageBox: с ним нельзя нормально работать. Никто не скажет, должен ли быть результат именно таким, потому что это слишком сложно проверить.
По‐моему, вы вообще единственный, кому здесь пришло в голову использовать какой‐либо GUI для вывода результатов.
Haskell, по‐видимости, имеет формат "word" "word1". Не проверял.
Ещё одно свидетельство, что результаты автором не проверялись: решение на Haskell делает все буквы маленькими перед тем, как начать их обрабатывать. Остальные так не делают.
А «внутренности наружу» — скорее всего имеются ввиду огромное число команд вроде «git unpack-file», предназначенных исключительно для использования их в скриптах.
У git нет огромного количества хуков (например, preoutgoing, все pre-{command}, …).
У git нелогичное распределение функциональность по командам: checkout создаёт ветки или обновляет дерево, push отправляет изменения или удаляет их на том конце, diff может показывать изменения между ревизиями, а может — status, причём сам status этого не умеет…
У git иногда плохая обработка аргументов командной строки (pull принимает сначала аргументы для merge, затем для fetch).
У git плохая документация — она настолько подробна, что отыскать нужное зачастую не представляется возможным. Вместе с неочевидным распределением функциональности по командам это создаёт проблемы.
Аналог revsets у git обладает куда как меньшими возможностями.
Многие команды git, показывающие список ревизий, не имеют возможности настройки формата вывода.
У часто используемых команд вроде push/pull есть ненужные обязательные аргументы: «git push origin :branch».
У git нет аналога «hg incoming».
У git нет удобного аналога «hg grep».
Большую часть претензий можно игнорировать или терпеть. Но не первые две.
И почти ничего из этого в моих текстах на английском, кроме кавычек (разумеется, не русских, но и не «"»).
А вообще можно просто прикрутить к стене полку под компьютер, избавление от уборки того стоит.
Fork root (fork автоматически ассоциируется с процессом, а не со специальным пользователем)
New similar terminal (многословно, но из всех вариантов — этот единственный, который я воспринимаю как надо; «Duplicate root» понятностью тоже не страдает)
Ничего лучше что‐то не придумывается.
man hypotнаписано прямо в заголовке:«hypot, hypotf, hypotl - Euclidean distance function». И ниже:В стандарте (POSIX) написано точно тоже самое. Так что ваша функция обязана отрабатывать ноль правильно.Только в man это продублировали в описании, а в стандарте написанои, но ниже только
Правда про первый класс не знаю — заматывают ли они им всю посылку или только часть и заматывают ли вообще. Посылки первым классом я не отправлял. Для писем первого класса вместо скотча может быть штампик.
Там написано, что это ISO-8613-3. И ещё там написано, что xterm не поддерживает 24‐битный цвет, вместо этого используя ближайший из 256‐цветной палитры (что интересно — человек, давший эту ссылку также пропустил сей факт). Эксперимент показал, что это утверждение верно, но konsole при той же последовательности выдаёт реальный 24‐битный цвет, а не приближение. Теперь мне надо искать какой‐то ещё терминал. Сейчас установлю ещё 13 терминалов и потом скажу, кто ещё поддерживает 24‐битный цвет.
\e[48;2;{R};{G};{B}m(фон, цвет текста — 48 вместо 38) (все цифры — десятичные, от нуля до 255).Я сейчас пилю vim для поддержки 24‐битного цвета и хотелось бы видеть эти цвета в качестве фактического стандарта. Известно, что, по крайней мере, konsole также поддерживает эти цвета.
import calendarкаждый раз (и зачем вообще оно проверялось)? Просто Python кэширует модули и последующие подключения производятся из словаря. Сreload(calendar)(python 2)/from imp import reload; reload(calendar)картина будет совсем другой, хотя что именно следует использовать зависит от того, зачем это вообще проверялось, может надо до кучи ещё и зависимости перезагружать.Кстати, сам модуль использует
year % 4 == 0 and (year % 100 != 0 or year % 400 == 0).c<C-p>с этими настройками вы получаете что‐то вродеcat file | grep …: то есть, строку, начинающуюся наcиз истории.cуже набрана. Также вы получаете не строку, содержащую c. И не строку, совпадающую с шаблоном. И не что‐то ещё.Кроме того, в каком терминале у вас работает
<C-S-r>? Терминалы вообще обычно посылают одну и ту же последовательность и для того, и для другого.<C-r>— не поиск по‐умолчанию? А как работает<C-S-r>я вообще не представляю: в xterm это то же, что и<C-r>(во всяком случае, с настройками по‐умолчанию). В urxvt тоже. В konsole (yakuake) это вообще клавиатурное сочетание, закрывающее вкладку (правда, не факт, что стандартное).По‐моему, вы вообще единственный, кому здесь пришло в голову использовать какой‐либо GUI для вывода результатов.
Это не ответ. Здесь все показывают сам скрипт.
"word" "word1". Не проверял.Ещё одно свидетельство, что результаты автором не проверялись: решение на Haskell делает все буквы маленькими перед тем, как начать их обрабатывать. Остальные так не делают.