Если вы используете Vim, то можно ничего не удалять, а написать :cq<CR>: тогда git будет считать, что он не смог запустить редактор и отменит rebase (:cquit заставляет Vim выйти с кодом возврата 1).
Есть хак для «просто забери»: прописываете в настройках удалённого репозитория, что хотите всё забирать себе и прописываете alias fu = pull --ff-only upstream:
Последняя строка для того, чтобы не push’ить по‐умолчанию что попало, вторая для того, чтобы иметь «резервную копию» всех ссылок. Вся соль в третьей: она говорит git «по‐умолчанию забирай все ветки».
Но поведение mercurial всё же более понятно и более удобно.
PS: Если вы под «просто забери» не имели ввиду «просто забери всё», то дело решается либо так же (но с заменой звёздочек на имена веток), либо явным git fetch origin master:master или git pull --ff-only origin master.
PPS: Сразу говорю, что git fu с моим alias’ом и моим workflow будет постоянно считать, что провалился. Просто git fetch будет проваливаться с сообщением, что не может делать fetch в текущую ветку, поэтому используется «pull в значении fetch, если текущей ветки нет в upstream, и pull в значении „сделай всё и подвинь текущую ветку“, если она есть». Но при этом после fetch будет проваливаться merge, т.к. он не знает, с чем сливать (что меня устраивает, т.к. я хотел сделать только fetch).
Вы сами-то поняли что сказали? Как вы можете говорить, что у вас есть права доступа к файлу, если вы их сами же и отобрали?
Права на запись и атрибуты файла — это разные сущности. Этим действием я ни у кого не отбираю права, я оставляю указание драйверу файловой системы, что ему надо делать с этим файлом. Поэтому root спокойно игнорирует отсутствие у него прав на запись, но не игнорирует атрибуты. Правда, несмотря на различный смысл, проверяется всё (атрибуты и права) практически в одном месте, по крайней мере в ядре linux.
Да ну? Делаете chattr +i filename или chattr +a filename от root’а и получаете неудаляемый (даже самим root’ом*) файл при наличии прав на него. Также можно при желании настроить AppArmor/SElinux, чтобы git не мог что‐то удалить (но при этом права, в т.ч. на запись будут). Не знаю, правда, что вернёт stat в последнем случае. Но в обоих случаях бага в ядре и рассыпавшейся файловой системы нет, а невозможность удалить файл есть.
* root всё же может удалить, если воспользуется chattr (а также прямым редактированием блочного устройства, монтированием файловой системы с использованием собственного драйвера, игнорирующего атрибуты, или любым другим из 100500 грязных хаков, недоступных для обычного пользователя).
Второй просмотренный 3D фильм мне запомнился тем, как я пытаюсь сфокусировать взгляд на каком‐то рисунке на поверхности стекла. Не то, что бы я не догадывался, что можно просто снять очки: никакое 3D не сделает фильм интересным. В остальных особого восторга от 3D не заметил. Впрочем, я вообще фильмы в кинотеатрах смотрю только «за компанию», а дома 3D нет.
Вопрос в том, что понимается под «стандартной клавиатурой». Со смартфона такое вводить жутко неудобно: те же прямоугольные скобки любят убирать на третий уровень. Особенно у меня: у моего телефона есть железная qwerty, но на ней нет фигурных, угловых и прямоугольных скобок, а также обратной косой черты, backtick и вертикальной черты. Что-то можно ввести, используя метод «нажать кнопку и держать», но не всё.
Если вы печатаете слепым методом, то, особенно на первых порах, часто случается, что одним пальцем вы набрали следующий символ, раньше чем успели набрать другим пальцем предыдущий. Актуально для печати любым количеством пальцев, кроме одного. Ну и кроме того us — далеко не единственная раскладка в мире. У меня dvorak и там qwerty выглядит как x,doky (могу немного ошибаться, т.к. печатаю по памяти со смартфона). Но u не находится рядом с w и здесь. Так можно опечататься, наверное, при наборе со слуха человеком, не понимающим, почему qwerty пишется так, как оно пишется, либо при использовании других раскладок (я не помню, что там в какой-нибудь azerty).
В ReST сделали просто: во‐первых, вы можете использовать любой из следующих символов для подчёркивания: ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~ (большинство символов использовать не рекомендуется). Во‐вторых, первым уровнем будет заголовок, который вы подчеркнули первым, независимо от того, как вы его подчеркнули. В‐третьих, следующий заголовок с другим стилем подчеркивания будет иметь второй уровень. Следующий заголовок с отличным от обоих предыдущих стилей будет иметь третий уровень и так далее. Попытка использовать уровень не в свою очередь (третий после первого или новый стиль подчеркивания где‐то, кроме как после заголовка наибольшего уровня) — ошибка. Недостаточная длина подчёркивания (оно должно быть, как минимум, такой же длины, что и заголовок (про fullwidth символы (= 2 символа подчёркивания) и диакритику (= 0 символов) парсер знает)) — предупреждение и никакого заголовка (предупреждение есть и в созданном HTML, и в stderr).
Я не знаю, как при обновлении ПО могут не обновиться настройки по‐умолчанию. Portage не трогает настройки, если они защищены, либо были изменены пользователем, но он всегда кладёт файлы со специальным именем с новыми настройками по‐умолчанию (или со старыми — он их не различает, что меня раньше изрядно злило) и напоминает про них при каждом запуске emerge. Мой скрипт позволяет мне сделать merge того, что положил portage и того, что имею я, ведя две ветки /etc в трёх каталогах (сам /etc, tip моей ветки без изменений в рабочем каталоге и tip ветки с настройками по‐умолчанию: существуют по техническим причинам (так намного проще скриптом сохранять настройки и делать merge)).
Сам скрипт здесь: bitbucket.org/ZyX_I/update-script. Сразу предупреждаю: медленный на множестве изменений, не поддерживает откат при <C-c> (вам придётся шастать по всем трём каталогам, откатывая изменения, если вы не подумали перед запуском) и при указании конкретных файлов для обновления требует указать --none, иначе будет спрашивать вас про все не указанный файлы. И я даже не пытался прикрутить автоматическое обновление после запуска emerge. Меня пока более‐менее устраивает.
Я уже вроде где‐то отвечал, почему она не подходит. Сейчас не помню всего, но одно нашёл точно — судя по коду при изменении настроек пакетным менеджером etckeeper делает commit. Мне это не нужно нафиг: я веду две ветки — одну с настройками по‐умолчанию, другую с собственными изменениями; после (пере)установок/обновлений делается commit в default и merge. И именно из‐за merge я держу там mercurial: откат мне практически никогда не требовался: большинство настроек легко откатываются либо по памяти, либо с использованием Vim с его persistent undo (ещё больше настроек заменяются на другие верные при обнаружении проблем после их изменения, а не откатываются).
Ещё, как я понял, он делает commit перед запускам пакетного менеджера. Такая самостоятельность мне тоже совершенно не нужна — в /etc часто есть изменения, которые я собираюсь откатить (т.к. это тестовые изменения/временный хак для исправления проблемы и т.д.), и «грязный» hg status мне служит для этого напоминанием. Это оказалось приятным дополнением к merge.
А вам точно нужна генерация на сервере? Вроде можно весь сайт было написать на JS и отправить хостится на github pages. Единственное но: данные придётся сохранять либо в URL (благо закладки синхронизируются всеми браузерами), либо привязывать к браузеру (local storage). Зато вас никто не будет обвинять в том, что вы сохраняете у себя конфигурацию AD и как‐то её используете.
Не помню такого в своей Gentoo. Вот медленное замусоривание, после которого проще переустановить, чем найти источники проблем — может быть. Особенно, если вы не очень опытный пользователь. Rolling release имеет свои преимущества: с ним очень сложно устроить большие проблемы при обновлении.
Я, кстати, весь /etc засунул под контроль mercurial. И поместил туда /var/lib/portage/world (оставив на прежнем месте symlink, т.к. это чуть ли не единственная принципиально не настраиваемая локация) (debian’овские --get-selections в Gentoo изначально удобно расположились в отдельном текстовом файле).
Не надо называть отдельный /boot бредом. Вам уже привели несколько причин, зачем это нужно. Если к вам эти причины не относятся или вам кажется, что они к вам не относятся, то это не значит, что отдельный /boot является бредом. Я его тоже не везде ставлю отдельным.
Genkernel, кстати, позволяет настраивать место, где будет происходить сборка, по‐умолчанию использует /var/tmp. Ничего подобного в документации к initramfs.conf я не нашёл.
Если вы не уверены в результате обновления или если результат оказался печальным, то это проще всего. И проще удалять файлы с помощью mkfs при заранее продуманном их распределении по блочным устройствам, чем думать, что надо указать rm, а что не надо.
Genkernel не пересобирает initramfs в /boot. Так что не =, во всяком случае, не у всех. Лучше пните того, кто писал программу для сборки initrd в вашем дистрибутиве.
И не надо пинать Black_Shadow: «у меня не работает, значит у всех так» — это тоже неверное утверждение. Он указал, при каких условиях у него работает. А вы не указали, при каких условиях у вас нет.
TuxOnIce умеет сохраняться в файл. Кстати: если вы включите swap и будете использовать для сохранения его, то у вас будут три проблемы: во‐первых, если оперативка занята и swap тоже, то никакого suspend не будет (я всегда решал эту проблему самым простым способом — увеличением либо оперативки, чтобы swap можно было включать непосредственно перед suspend, либо swap’а). Во‐вторых, TuxOnIce вытесняет в swap всё, что может, как будто у вас закончилась оперативная память — в итоге система загрузится довольно быстро, но будет очень сильно тормозить, поскольку все страницы в swap’е. А swapoff работает явно не со скоростью чтения с диска. В‐третьих, TuxOnIce вроде имеет привычку сохранять кэши, которые вам из‐за второй проблемы совершенно ни к чему: я не смотрел, действительно ли это так, но echo 1 > /proc/sys/vm/drop_caches могло «починить» нехватку памяти.
Не знаю, что из этого отностится к suspend’у в файл.
git rebase --autostashи соответствующая настройкаrebase.autostash. Я, правда, не в курсе, когда это появилось. У меня версия 1.8.5.5.:cq<CR>: тогда git будет считать, что он не смог запустить редактор и отменит rebase (:cquitзаставляет Vim выйти с кодом возврата 1).fu = pull --ff-only upstream:Последняя строка для того, чтобы не push’ить по‐умолчанию что попало, вторая для того, чтобы иметь «резервную копию» всех ссылок. Вся соль в третьей: она говорит git «по‐умолчанию забирай все ветки».
Но поведение mercurial всё же более понятно и более удобно.
PS: Если вы под «просто забери» не имели ввиду «просто забери всё», то дело решается либо так же (но с заменой звёздочек на имена веток), либо явным
git fetch origin master:masterилиgit pull --ff-only origin master.PPS: Сразу говорю, что
git fuс моим alias’ом и моим workflow будет постоянно считать, что провалился. Простоgit fetchбудет проваливаться с сообщением, что не может делать fetch в текущую ветку, поэтому используется «pull в значении fetch, если текущей ветки нет в upstream, и pull в значении „сделай всё и подвинь текущую ветку“, если она есть». Но при этом после fetch будет проваливаться merge, т.к. он не знает, с чем сливать (что меня устраивает, т.к. я хотел сделать только fetch).chattr +i filenameилиchattr +a filenameот root’а и получаете неудаляемый (даже самим root’ом*) файл при наличии прав на него. Также можно при желании настроить AppArmor/SElinux, чтобы git не мог что‐то удалить (но при этом права, в т.ч. на запись будут). Не знаю, правда, что вернётstatв последнем случае. Но в обоих случаях бага в ядре и рассыпавшейся файловой системы нет, а невозможность удалить файл есть.* root всё же может удалить, если воспользуется
chattr(а также прямым редактированием блочного устройства, монтированием файловой системы с использованием собственного драйвера, игнорирующего атрибуты, или любым другим из 100500 грязных хаков, недоступных для обычного пользователя).! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~(большинство символов использовать не рекомендуется). Во‐вторых, первым уровнем будет заголовок, который вы подчеркнули первым, независимо от того, как вы его подчеркнули. В‐третьих, следующий заголовок с другим стилем подчеркивания будет иметь второй уровень. Следующий заголовок с отличным от обоих предыдущих стилей будет иметь третий уровень и так далее. Попытка использовать уровень не в свою очередь (третий после первого или новый стиль подчеркивания где‐то, кроме как после заголовка наибольшего уровня) — ошибка. Недостаточная длина подчёркивания (оно должно быть, как минимум, такой же длины, что и заголовок (про fullwidth символы (= 2 символа подчёркивания) и диакритику (= 0 символов) парсер знает)) — предупреждение и никакого заголовка (предупреждение есть и в созданном HTML, и в stderr).Сам скрипт здесь: bitbucket.org/ZyX_I/update-script. Сразу предупреждаю: медленный на множестве изменений, не поддерживает откат при
<C-c>(вам придётся шастать по всем трём каталогам, откатывая изменения, если вы не подумали перед запуском) и при указании конкретных файлов для обновления требует указать--none, иначе будет спрашивать вас про все не указанный файлы. И я даже не пытался прикрутить автоматическое обновление после запуска emerge. Меня пока более‐менее устраивает.Ещё, как я понял, он делает commit перед запускам пакетного менеджера. Такая самостоятельность мне тоже совершенно не нужна — в /etc часто есть изменения, которые я собираюсь откатить (т.к. это тестовые изменения/временный хак для исправления проблемы и т.д.), и «грязный»
hg statusмне служит для этого напоминанием. Это оказалось приятным дополнением к merge.Я, кстати, весь /etc засунул под контроль mercurial. И поместил туда /var/lib/portage/world (оставив на прежнем месте symlink, т.к. это чуть ли не единственная принципиально не настраиваемая локация) (debian’овские
--get-selectionsв Gentoo изначально удобно расположились в отдельном текстовом файле).Genkernel, кстати, позволяет настраивать место, где будет происходить сборка, по‐умолчанию использует /var/tmp. Ничего подобного в документации к initramfs.conf я не нашёл.
rm, а что не надо.=, во всяком случае, не у всех. Лучше пните того, кто писал программу для сборки initrd в вашем дистрибутиве.И не надо пинать Black_Shadow: «у меня не работает, значит у всех так» — это тоже неверное утверждение. Он указал, при каких условиях у него работает. А вы не указали, при каких условиях у вас нет.
swapoffработает явно не со скоростью чтения с диска. В‐третьих, TuxOnIce вроде имеет привычку сохранять кэши, которые вам из‐за второй проблемы совершенно ни к чему: я не смотрел, действительно ли это так, ноecho 1 > /proc/sys/vm/drop_cachesмогло «починить» нехватку памяти.Не знаю, что из этого отностится к suspend’у в файл.