По мнению первого заместителя комитета Госдумы по информационной политике Леонида Левина, анонимайзеры используют люди, которые намереваются совершить какие-то незаконные действия, или те, кому есть что скрывать.
По-моему, тут все просто. Всем есть, что скрывать. У всех есть право скрывать информацию о себе. Даже если это информация о намерении совершить незаконное действие. Запрет на скрытие подобной информации граничит с нарушением права не свидетельствовать против себя.
В воксельных движках кубики используются только для хранения данных о структуре и форме объектов и для манипуляций с этими данными. Потому что манипулировать структурой кубиков проще для процессора, чем манипулировать сеткой полигонов. Но графический процессор не умеет работать с кубиками. Поэтому используются алгоритмы для создания сетки полигонов на основе кубиков. Подобная генерация поверхности делается не каждый кадр, а только при изменениях структуры объекта. При этом могут использоваться алгоритмы для сглаживания поверхности, чтобы кубики были не так очевидны.
Это как с квейком, до того, как там появился сlient prediction — у Кармака был быстрый интернет T1 и он все делал с расчетом на маленькие пинги до 200 мс. Так и тут, наверняка у Кармака стоял SSD, с которого все замечательно стримится.
Использую восьмерку дома где-то с полгода. Все взаимодействие с ОС сводится к запуску трех с половиной программ: IDE, браузер, игрушки и так по мелочи. Принципиальной разницы с семеркой в этом смысле не вижу. На изменения в интерфейсе реагирую нормально — как было пара кликов для типичных задач, так и осталось. Выучить новые три клика вместо старых — вполне посильная задача. «Настроил» под свои три программы стартовый экран.
Согласен, что для мейнтейнеров ядра Linux сложившийся процесс является довольно удобным. Но не все пользователи GIT — разработчики ядра и далеко не всегда для манипуляций с комитами есть такая веская причина, а не простое желание сделать красиво. Если бы заголовок у поста был «Зачем разработчики ядра Linux редактируют свои коммиты», то возможно было бы меньше недопонимания с моей стороны и со стороны других отписавшихся здесь.
Ревью делается для конечного результата, а не для диффов в каждом коммите. Поэтому не важно, сколько там коммитов и сколько раз один кусок кода переписывался в них. Время на ревью в таком случае зависит от общего количества изменений и их сложности, а не от количества коммитов. В историю всего репозитория почти не смотрю. Смотрю на историю изменения отдельных модулей и файлов, если есть какие-то проблемы и нужно понять, почему они возникли.
Бывают моменты, когда в коде натуральные КРОВЬ КИШКИ РАСЧЛЕНЕНКА на протяжении целого дня, а то и нескольких.
Такое может быть, если не задумываться об атомарных изменениях. Да, для этого нужно изменить подход к программированию, разбивать на мелкие задачи и фокусироваться на них. Но это реально и лично мне это не мешает, а наоборот — помогает сосредоточиться. До этого у меня тоже часто были подобные ситуации — делаю какие-то мелкие изменения, они тянут за собой все больше и больше кода и не успеешь обернуться, как вся система сломана и непонятно, за что хвататься, чтобы привести все в порядок. Я стараюсь до такого не доводить, фокусируясь на законченных коммитах и небольших не калечащих изменениях.
что мне написать в коммит месседж, когда я переключаю контекст, а из текущих изменений — одна измененная константа, скажем?
Писать, что изменена такая-то константа. Можно еще добавить — зачем. Это лучше, чем temp, wasd, 111 и прочие.
Плюс к этому правило «коммитить часто» порождает множество коммитов на каждую мелкую фичу, которые сильно захламляют историю.
Вот. Подобное мышление — это уже следствие того, что редактирование истории становится частью рабочего процесса. Как пользователь меркуриала могу сказать, что у меня нет такого понятия, как захламление истории. Для ее организации я использую ветки и таги. Мне без разницы, сколько у меня коммитов в ветках, в большинстве случаем меня интересуют только последние.
Иначе — это когда историю редактировать нельзя. В этом случае имеет смысл руководствоваться как минимум двумя правилами для коммитов: писать содержательное сообщение, которое описывает ключевые моменты, и делать коммит законченным, чтобы приложение хотя бы компилировалось. Эти условия не мешают коммитить часто и при этом, глядя на их историю, не возникает желания ее переписать.
Другими словами пользователи GIT редактируют историю «потому что могут».
Касательно вашего примера — коммиты с такими сообщениями действительно держать в истории неприятно. Даже во временном бранче. Особенно если некоторые из них не компилируются или не проходят тесты или приводят к ошибке во время выполнения. Если разрабатывать и коммитить в таком стиле, то GIT с его вольностями по отношению к истории кажется более предпочтительным.
Конечно есть именованные бранчи, но коммиты у ним не привязаны
Об этом и речь — глядя на коммит, нельзя сказать к какому бранчу он относится. Т. е. к какой фиче-фиксу как вариант. Сообщение слишком специфично и не содержит такой информации, так как фича одна, а коммитов много. Возможно из-за этого и приходится впоследствии шаманить с коммитами, чтобы по ним было понятно, к чему они собственно относятся.
При наличии настоящих именованных бранчей (как в DVCS на букву М) необходимости что-то делать с кучей мелких коммитов в одном бранче нет.
Другими словами у пользователей GIT нет именованных бранчей, поэтому для того, чтобы дерево коммитов оставалось читабельным, им приходится ужимать бранчи до одного коммита.
По-моему, тут все просто. Всем есть, что скрывать. У всех есть право скрывать информацию о себе. Даже если это информация о намерении совершить незаконное действие. Запрет на скрытие подобной информации граничит с нарушением права не свидетельствовать против себя.
Писать, что изменена такая-то константа. Можно еще добавить — зачем. Это лучше, чем temp, wasd, 111 и прочие.
Вот. Подобное мышление — это уже следствие того, что редактирование истории становится частью рабочего процесса. Как пользователь меркуриала могу сказать, что у меня нет такого понятия, как захламление истории. Для ее организации я использую ветки и таги. Мне без разницы, сколько у меня коммитов в ветках, в большинстве случаем меня интересуют только последние.
Касательно вашего примера — коммиты с такими сообщениями действительно держать в истории неприятно. Даже во временном бранче. Особенно если некоторые из них не компилируются или не проходят тесты или приводят к ошибке во время выполнения. Если разрабатывать и коммитить в таком стиле, то GIT с его вольностями по отношению к истории кажется более предпочтительным.
При наличии настоящих именованных бранчей (как в DVCS на букву М) необходимости что-то делать с кучей мелких коммитов в одном бранче нет.