В другом потоке:
dd if=/dev/zero of=/dev/sdc2 bs=1024 count=1024
mkfs.reiserfs /dev/sdc2

Вот я теперь думаю: я был не прав или всё-таки оно не должно было упасть?
Что ответит Александр ДрузьКО?

Редактирование истории в git

Более строго следует говорить не о "редактировании" или "изменении" истории,
а о cоздании "альтернативной" истории. Если специально ничего не предпринимать,
в репозитории git остаются все объекты "старой" истории, соответствующие
предыдущим коммитам и версиям файлов.
На эти объекты не будут "ссылаться" ветки, но если Вы вспомните их SHA1-ключи,
либо как-то специально позаботитесь их "пометить" (тэгом, или другой веткой),
то старая история будет c точки зрения git "ничем не хуже" новой.

Почти во всех командах git можно ссылаться на коммиты любым способом:
 - с помощью SHA1-ключа,
 - с помощью имени ветки (если это последний коммит на ветке),
 - с помощью тэга (если вы его предусмотрительно поставили git tag),
 - c помощью специальных имён, например HEAD - последний коммит на
   данной ветке, HEAD^ - предпоследний (точнее, первый предок
   последнего коммита) и т.п. Подробности см. git-rev-parse --help
Ниже в командах, которые допускают любую идентификацию коммита, я буду
указывать в качестве аргумента <id>, или <id-...>. Если допускается только
имя ветки, указывается <ветка>.

Для начинающих я рекомендую приступая к редактированию истории пометить
все ключевые точки тэгами. Их хорошо видно в gitk.
Только не забудьте их потом удалить git tag -d

В понятие истории git я буду включать не только совокупность коммитов
git-а, но и содержание рабочего каталога (да простят меня потомки).

Типовые задачи редактирования истории:

1. Отказаться от всех изменений в рабочем каталоге (аналог revert в svn).
   Кошерный способ: git checkout -f
   Отказаться от части изменений можно с помощью: git checkout <path>
   НО: git checkout . не удалит, например, вновь добавленных файлов.
   Более жёсткий способ удалить _все_ изменения: git reset --hard HEAD

2. "Сохранить" изменения (состояние) рабочего каталога.
   git stash
   При этом рабочий каталог "очищается" до HEAD, а сохранённые изменения
   можно в последствии "применить" к текущему, либо к любому другому
   состоянию рабочего каталога с помощью git stash apply
   В частности, это позволяет "переносить" изменения между ветками
   (хотя, лучше их оформлять как коммиты, и оперировать потом уже с ними).

3. Отредактировать/дополнить последний коммит:
   git commit --amend
   Можно применять даже если Вам просто понадобилось переписать commit-log
   (например, Вы его "недописали" или он оказался не в той кодировке).
   Фактически при выполнении этой операции будет создан _другой_ commit
   object, и HEAD ветки будет связан с ним. (Старый объект в репозитории
   git тоже сохранится).

4. "Отказаться" от нескольких последних коммитов в истории (в частности,
    от последнего)
   Создать новую ветку new в нужной нам точке истории и переставить на
   неё существующую:
   git checkout <id> -b new
   git branch -M <нужная нам ветка>
   Например, отказаться от последнего коммита на ветке master (если мы
   на нём находимся), можно так:
   git checkout HEAD^ -b new_master
   git branch -M master
   После первой команды мы находимся "на один коммит назад" и создали там
   новую ветку с именем new_master (текущей веткой является new_master).
   После второй команды мы "переименовали" new_master в master, -M позволяет
   проигнорировать, что master уже есть.
   Тоже самое можно сделать одной командой:
   git reset --hard <id>
   Но это менее безопасно (см. ниже).

5. "Переставить" метки веток.
   git reset [--ключ] <id>
   Позволяет "передвинуть" текущий HEAD (и метку ветки) на заданный коммит.
   Есть три варианта, задаваемых ключами:
    --hard - "выкидывает" всё текущее состояние рабочий копии, вы оказываетесь
             на коммите <id>, как будто после него ничего не было;
             Т.е. это просто "перестановка ветки".
    --soft - "сохраняет" изменения в рабочей копии (и в "индексе" git) и добавляет
             к ним изменения из "истории" от <id> до точки, из которой мы переходим.
             Более подробно см. п. "Слияние нескольких коммитов в один".
    --mixed - (по умолчанию) - ведёт себя как --soft, но не изменяет состояние
             "индекса" git (оно будет соответствовать коммиту <id>, на который мы
             перешли) - новые и изменённые файлы не считаются "добавленными" в индекс,
             т.е. в отличии от --soft для них требуется явно делать git add,
             git rm, .etc
   Поскольку git reset (особенно --hard), позволяет "потерять" последнее
   положение ветки (т.е. оставить HEAD "непомеченным"), следует использовать
   эту команду с осторожностью.

6. Слияние нескольких коммитов в один.
   Если это "последние" коммиты в истории этой ветки:
   git reset --soft <id>
   git commit -a -s [--amend]
   Первая команда позволяет "отскочить" HEAD на несколько коммитов назад, при
   этом сохранив все "изменения" этих коммитов в рабочем каталоге.
   Например, git reset --soft HEAD^^ позволит "объединить" изменения последнего
   и предпоследнего коммитов.
   Если мы хотим "добавить" к этим изменениям, изменения из коммитов с другой
   ветки, нам поможет git cherry-pick --no-commit <id>
   Эта команда "добавляет" изменения коммита в рабочий каталог и в индекс, но не
   выполняет операцию commit.

7. Удаление нескольких коммитов "внутри истории". git-rebase magic
   Например, у Вас есть история ветки:
    ...-(N-5)-(N-4)-(N-3)-(N-2)-(N-1)-(N) - ветка
   и вам захотелось удалить коммиты (N-4)-(N-2) включительно.
   Это можно сделать с помощью команды git-rebase:
   git-rebase --onto <ветка>~5 <ветка>~2 <ветка>
   Например, git-rebase --onto master~5 master~2 master
   Нотация <id>~<n> означает n-ый коммит назад, т.е. в данном случае:
    - master - (N)
    - master~2 - (N-2)
    - master~5 - (N-5)
   Смысл операции git-rebase --onto <id-newbase> <id-upstream> <id-head>:
    1) Переключиться на коммит <id-head> (== git checkout <ветка>, если
       <id-head> - это HEAD ветки)
    2) Начать новую ветку от точки <id-newbase>
    3) "Поместить" на новую ветку коммиты от <id-upstream> до <id-head>,
       не включая <id-upstream>
    4) Если <id-head> - это HEAD ветки, переставить <ветку> на то, что получилось
   В данном случае:
   От коммита (N-5) мы начинаем "применять" коммиты (N-1) и (N), и переставляем
   метку ветки, в результате чего получается "новая история":
        (N-1)'-(N)' - ветка
         /
   ...-(N-5)-(N-4)-(N-3)-(N-2)-(N-1)-(N)

8. Объединение коммита с "внутренним" коммитом в истории.
   Например, в коммите <id-src> Вы исправили ошибку в "старом исправлении" <id-dst>,
   которое было несколько коммитов назад.
   Последовательность действий:
   1) Создать новую ветку new_branch от коммита <id-dst>, который надо
      поменять (дополнить).
      git checkout <id-dst> -b new_branch
   2) Сделать cherry-pick коммита <id-src>, который вы хотите "приплюсовать" к
      внутреннему.
      git cherry-pick --no-commit <id-src>
   3) "Дополнить" последний коммит изменениями из рабочего каталога.
      git commit --amend
   4) Добавить в новую историю последовательность "правильных" коммитов:
      git rebase --onto HEAD <id-первый коммит>^  <id-последний коммит>
   5) Переставить ветку на новый HEAD
      git branch -f <имя ветки>

   Пояснения требуют два последних действия:
     git rebase в данном случае добавляет нужную последовательность коммитов
     "в голову" новой ветки, но если <id-последний коммит> - это не HEAD
     старой ветки, то после git rebase новый HEAD не будет соответствовать
     ни какой ветке ! (так уж работает git rebase)
     Для этого требуется последняя операция, она явно переставляет ветку
     на HEAD.

   Если наше исправление было бы не закоммичено, можно было воспользоваться
   git stash и git stash apply вместо git cherry-pick.

9. Редактирование "внутреннего" коммита.
   Действия аналогичны п.8, но проще. Пусть мы находимся на ветке <имя ветки>.
   1) Извлечь коммит <id-dst>, подлежащий редактированию; ветку new_branch
      создавать при этом не обязательно, но желательно:
      git checkout <id-dst> [-b new_branch]
   2) Исправить код, "дополнить" последний коммит изменениями из рабочего
      каталога.
      git commit -a --amend
   3) Добавить в новую историю последовательность "правильных" коммитов:
      git rebase --onto HEAD <id-dst> <имя ветки>
   4) Удалить ветку new_branch, если она была создана на шаге 1)
      git branch -D new_branch

   Специально переставлять ветку <имя ветки> в данном случае не требуется, т.к.
   в команде git rebase в п. 3) в качестве последнего аргумента было имя ветки,
   а не просто SHA1-id. В такой ситуации эта команда "автоматически" переставит
   ref ветки.

10. rebase ветки с помощью git rebase.
    git rebase <upstream-branch>
    Эта операция подробно рассмотрена в разъяснениях Никиты по идеологии и
    сценариям использования git.
    Не следует относится к git rebase "формально": например, если Вы считаете,
    что некоторые коммиты с ветки разумнее было бы переместить на master, можно
    "продублировать" их на master с помощью git cherry-pick, после чего сделать
    git rebase. После этого, с веки эти коммиты волшебным образом исчезнут.

11. "Откат" отдельного коммита.
    Строго говоря, это не редактирование истории: просто автоматически добавляется
    коммит (либо, изменение в рабочей копии), "отменяющее" заданный коммит.
    git revert [--no-commit] <id>
    Эту возможность следует использовать если Вы не хотите "честно" редактировать
    историю. Например, коммит надо откатить только на одной из ветвей, либо
    этот коммит был "очень давно", и не хочется перестраивать из-за него всю
    историю целиком.

(cc) Mike Chistolinov

Таки нет! Нам все эти годы врали! Английское Copyright обозначает только отчуждаемые авторские права. А к неотчуждаемым правам отношения не имеет.

А вы говорите, что изюм это сушеный виноград…

ЗЫ В моем репозитории в секции main лежат бэкпорты под все актуальные дистрибутивы Debian/Ubuntu.

Upd: Лицензия на второй файл cc-3.0-by-sa, на первый, скорее всего тоже, но надо еще уточнить, потому что я использовал за основу творчество Сэма Хосевара, напишу ему и спрошу.

#!/bin/sh

rm -f /etc/bind/mydns/db.*
echo -n > /etc/bind/named.conf.mydns

echo "select origin from dns_soa where active='Y';" | mysql --defaults-file=/etc/mysql/debian.cnf dbispconfig | while read DOMAIN;do
[ "$DOMAIN" = "origin" ]&&continue

mydnsexport "$DOMAIN" > /etc/bind/mydns/db."$DOMAIN"

XFER=$(echo "select xfer from dns_soa where origin=\"$DOMAIN\"" | mysql --defaults-file=/etc/mysql/debian.cnf dbispconfig | tail -n1|tr , \;| sed -e 's/;;/;/g' -e 's/^;$//')\;

echo "zone \"$DOMAIN\" { type master; allow-transfer { $XFER }; file \"/etc/bind/mydns/db.$DOMAIN\"; };" >> /etc/bind/named.conf.mydns

done

/etc/init.d/bind9 reload > /dev/null

где /etc/mysql/debian.cnf – это файл содержащий параметры доступа к mysql:

[client]
host     = localhost
user     = root
password = password
socket   = /var/run/mysqld/mysqld.sock

Правда, как оказалось, mydnsexport генерирует невалидный файл зоны, так что пришлось его слегка пропатчить:

diff -rNu mydns-1.2.8/src/lib/rr.c mydns-1.2.8.patched/src/lib/rr.c
--- mydns-1.2.8/src/lib/rr.c	2009-02-03 12:15:26.000000000 +0300
+++ mydns-1.2.8.patched/src/lib/rr.c	2009-09-27 05:00:26.000000000 +0400
@@ -866,6 +866,7 @@
 			     "%s%s%s"
 			     "%s%s"
 			     "%s%s"
+			     "%s"
 			     "%s",

 			     columns,
@@ -891,8 +892,9 @@
 			     (filter)? " AND " : "",
 			     (filter)? filter : "",

+			     " ORDER BY name,type",
 			     /* Optional sorting */
-			     (mydns_rr_use_stamp)? " ORDER BY stamp DESC" : "");
+			     (mydns_rr_use_stamp)? ",stamp DESC" : "");

   RELEASE(namequery);

Ну и вставить вызов скрипта в крон. Извращение, но работает.

Всем привет.

Как уже всем должно быть известно, в этом году Лицею исполняется 20 лет. В связи с этим планируется проведение встреч выпускников. Так как народу суммарно получается очень много, то было решено провести это мероприятие в 2 этапа: выпуски до 98го года включительно будут собираться 19го сентября, а с 99го по 2005 – 28го ноября.

Кашкарова сказала, что с Ольгой Николаевной у нее связь есть и, вероятно, она придет.

Официальная программа для нашего выпуска пока выглядит так: часов в 11 сбор в Лицее в отдельной аудитории (классами или парами классов), в 12 часов начало официальной части в актовом зале. Планируется, что Кашкарова с Чудовым расскажут о том что и как сейчас происходит в Лицее, покажут видео о лицее вообще и нарезку архивов, касающихся нашего выпуска. Ну и, естественно, аэробика, чтобы добить эту программу до положенных полутора часов =)

Также планируется в каком-то виде экскурсия по Лицею.

После этого можно еще какое-то время походить по Лицею, пообщаться с преподавателями (Обещали постараться собрать не только тех, кто работает в Лицее сейчас, но и тех, кто работал во время нашего там обучения.), посмотреть что к чему. После этого можно, например, пойти классом в какой-нибудь кабак чтобы продолжить там.

Планы пока что предварительные, возможно что-то будет скорректировано по результатам сентябрьской встречи.

Если у кого-то есть желание принять участие в официальной программе с песней, пляской или иным цирковым номером – то можете обращаться к Кашкаровой либо напрямую, либо, если хотите, через меня.

Опять же если есть какие-то предложения/пожелания – их можно высказывать.

Кашкарова с Чудовым очень боятся возможного количества участников и даже кагбе намекали, что если кому неинтересно, то тянуть их на встречу не надо, тем не менее, передайте по возможности эту информацию своим знакомым из других классов и других выпусков, потому что из нашего
выпуска на собрании присутствовали только Алла из XI-2-99 и я.

ЗЫ А новый бассейн на территории Лицея действительно построили

Со всеми замечаниями как всегда на root@runix.org.

Cheers.

Итак, Автофрамос ввозит машину. Цена машины: 426т.р.
С нее снимают налог 1,8евро на кубик: 162т.р.
Потом еще и c мощности 194р. за 0,75киловатт: 33т.р.
Дальше мне очень нравится: взимается еще 18%, с получившейся суммы.
Незаметно машина дорожает до 732т.р.
В нашей стране умеют делать деньги.

ЗЫ А под французским именем-то скрывается кореец.

Неочевидное тут вот что:
закрывать тикеты надо тогда, когда коммит попадает на master (такая у нас модель разработки), соответственно надо отлавливать мержи и в случае мержа просматривать смерженные коммиты.

Upd: Гит оказался умнее меня и сам (rev-list) выводит коммиты со смерженных веток. Поэтому всё намного проще и получившийся скрипт даже и не интересен ни разу.

Скрипт получился такой:

#!/bin/sh
# This script is run after receive-pack has accepted a pack and the
# repository has been updated.  It is passed arguments in through stdin
# in the form
#  oldrev newrev refname
# For example:
#  aa453216d1b3e49e7f6f98441fa56946ddcd6a20 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master

TRAC_HOOK="/srv/git/hooks/trac-post-commit-hook"
TRAC_DIR="/srv/trac/stand"

procrevs() {
    while read gitrev; do
	"$TRAC_HOOK" -p "$TRAC_DIR" -r "$gitrev"
    done
}

while read OLD NEW NAME;do
	test "$NAME" == "refs/heads/master"||continue
	git rev-list --no-merges "$OLD..$NEW"|procrevs
done

Где TRAC_HOOK – это trac-post-commit-hook из дистрибутива trac, TRAC_DIR – каталог с проектом trac. В самом trac’е должен быть включен и настроен плагин trac-git.

Пингвины откладывают яйца? Галагтеко опасносте?

В итоге всё уехало на конец июня. Но таки надо. Подробности тут.
Если вдруг не подписаны, то подписаться на список можно тут, только не забудьте указать имя.

Мой новый ключ:

pub   2048R/2AAC33F1 2009-05-18
Отпечаток ключа = 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1
uid                  Alexander GQ Gerasiov <gq@cs.msu.su>

Подробнее: gpg-transition-gq-2009-05-18.txt.

PS Если кто-то хочет обменяться подписями – можете отмечаться в комментах.

Хотя, с другой стороны, за такие деньги…

Почитал внимательнее minix3.org. Таненбаум, похоже, понял, что сказки про микроядро не интересны никому, кроме гиков. Теперь он упирает на BSD-лицензию и смотрит на проприетарные встроенные системы как целевую аудиторию.
В общем даже интересно. Где бы найти немножко времени, чтобы посмотреть на код…