Вы задали хороший вопрос, возможно я напишу заметку о бардаке, который творится в arch/. Но если кратко, то arch/*/boot содержит для каждой архитектуры собственные библиотеки, т.к. на момент работы того кода основная часть ядра ещё не декомпрессирована.
Поправил ещё раз с учётом вашей формулировки. Спасибо. -m как раз причём, так как пользователям часто лень экранировать или нажимать Enter посреди сообщения в вызове git commit -m … или они вообще забывают о такой возможности, и таким образом провоцирует запихнуть всё в одну строку. Почему я назвал стиль subversion? Потому как там это усилинно навязывалось (вот не помню такого в CVS), а ещё git svn при конвертировании из / в просто шедевры обрезания делает. Но окей, я заменил.
Во втором случае как раз мы говорим о фиче-бранче, то есть залили в мастер и забыли. Можно удалять, переформатировать в тег, всё что угодно. Поэтому продолжение последовательности скорее такое git push myFeature:master; git branch -m myNewFeature.
Третий пункт, таки да, если я правильно понял участника той беседы.
Поправил текст со ссылками на книгу. Там описывается обычная структура сообщения.
Про wip: комит, который не готов и может быть далее либо сведён с другим, либо быть fixup'ом, либо быть удалённым. Как вы сами говорите, такое соглашение.
Раскрыл подробнее тему второго случая.
Третий же по-моему очевиден, портить историю в публичных проектах — моветон. Портить историю у себя внутри, себе же хуже, концов не найдёшь кто, что и когда менял. Тем не менее дописал пару фраз.
Зачем два раза один и тот же комментарий?
Численные измерения можете провести сами, так как ABI утверждает только передачу первых параметров функции через регистры, остальное — через стек. Обращение к памяти гораздо дороже регистров, особенно, если при этом инвалидируется линия в кэше.
Ну, как видите конца света не наступило, так что и новые архитектуры, будучи изобретёнными, будут учитывать особенности и стандартов, и де факто существующих на рынке ОС.
Программа работает не в виртуальном пространстве, а на реальном железе. Всё определяется железом, если мы не рассматриваем виртуальные машины. Так что как раз стандарт ЯП побоку, если он противоречит архитектуре.
Это 5! Не слышал раньше.
git commit -m "wip 2"
.git commit -m …
или они вообще забывают о такой возможности, и таким образом провоцирует запихнуть всё в одну строку. Почему я назвал стиль subversion? Потому как там это усилинно навязывалось (вот не помню такого в CVS), а ещёgit svn
при конвертировании из / в просто шедевры обрезания делает. Но окей, я заменил.Во втором случае как раз мы говорим о фиче-бранче, то есть залили в мастер и забыли. Можно удалять, переформатировать в тег, всё что угодно. Поэтому продолжение последовательности скорее такое
git push myFeature:master; git branch -m myNewFeature
.Третий пункт, таки да, если я правильно понял участника той беседы.
Поправил текст со ссылками на книгу. Там описывается обычная структура сообщения.
Про wip: комит, который не готов и может быть далее либо сведён с другим, либо быть fixup'ом, либо быть удалённым. Как вы сами говорите, такое соглашение.
Раскрыл подробнее тему второго случая.
Третий же по-моему очевиден, портить историю в публичных проектах — моветон. Портить историю у себя внутри, себе же хуже, концов не найдёшь кто, что и когда менял. Тем не менее дописал пару фраз.
В остальном, если сделаете такие измерения, то я обязательно вставлю ссылку в статью.
Численные измерения можете провести сами, так как ABI утверждает только передачу первых параметров функции через регистры, остальное — через стек. Обращение к памяти гораздо дороже регистров, особенно, если при этом инвалидируется линия в кэше.