Как удалить коммит, который не принадлежит ни одной ветке, из git? Выполнить на сервере git gc.

Как удалить такой же коммит с GitHub? Похоже, что никак [1, 2], ну или через поддержку или удаление всего репозитория. В GitLab такая функция есть.

Разумеется, сборка мусора — очень непростая задача.

В недавней истории с xz примечательны не только технические детали, но и социальный аспект. Вкратце, от основного мейнтейнера довольно токсично требовали улучшений и ответственности перед сообществом. Такая история не очень нова: например, несколько лет назад создатель actix, одного из самых быстрых тогда веб-серверов на Rust, был на грани удаления репозитория, но в итоге все закончилось нормально (хотя там и к самому разработчику были вопросы).

“Знаете, я и сам своего рода opensource-разработчик”. Одна из зон моей ответственности — первичная фильтрация поступающих запросов от пользователей (за год с небольшим прокомментировал больше чем на 1000 тикетов 🤯). И сначала я довольно дотошно отстаивал позицию “пользователь всегда прав, если он не даун”, да и тяжело было с некоторыми не соглашаться, когда они критиковали продукт. Но через год мое отношение к пользователям немного сместилось.

Увы, есть люди, отношение которых напоминает поведение стереотипных теток с барахолок, которые будут требовать от тебя доставку на дом вещи, которую отдаешь бесплатно, а потом еще навалят говна, что она неидеального качества. У нас есть “любимчики”, которые могут вылить поток сознания перемешанный с несвязной критикой продукта или добавить в заголовок текст ошибки и приложить проект на 10 000 строк, на котором она воспроизводится. До ядерных угроз пока не дошло, но некоторые ходят прям по грани Code Of Conduct. Разумеется, это не означает, что все такие, нормальных и адекватных — большинство. Но хорошо оформлять тикеты, заботясь о продукте, сообществе и разрабах, а не только своей проблеме, мало кто умеет.

До меня наконец дошло просветление, что в данном случае с большой силой не приходит “большая ответственность”. Продукт с открытым исходным кодом, в лицензии четко написано, что гарантий никаких не даем, предоставляется бесплатно. Если что-то не нравится — либо помоги (хорошим тикетом или PR), либо форкни, либо найди что-то другое. Говорить “нет” и закрывать мусорные тикеты — это нормально. Мысли вроде очевидные, но за год мне стала гораздо ближе и понятнее позиция “старожилов”, которым проще закрыть мутный тикет и подождать нормальный, если проблема действительно существует, чем пытаться найти в нем что-то полезное.

Хорошая мини-игрулька, в которой можно потренироваться не только в цветовосприятии, но и с бинарным поиском.

А отдельный лайк — за то, что это простая веб-страничка на 300 строк, без зависимостей, с CSS и ванильным JS прямо внутри HTML.

Неплохая статья, в которой сравниваются лонг-поллинг, веб-сокеты, server-side events и новый стандарт, WebTransport. Сравнение немного поверхностное, но хорошо рассказывает об основных плюсах и минусах этих технологий.

Делать что-то на винде в консоли — это пытка, особенно после долгих лет на Linux. Стольких базовых вещей нет, просто жуть. Самое отстойное, что нет даже простенького текстового редактора, а это было бы удобно в случае, если что-то заставили надо сделать по ssh. Однако если на машине стоит git, то в нем есть подарок — nano и vim. Т.е. можно редактировать файлы через

> "C:\Program Files\Git\usr\bin\nano.exe" filename.txt

В той же папке еще навалом линуксового добра: bash, cat, cp, grep, openssl, tar и т.п.

Интересная статья про frame pointer — указатель на верхушку стека вызовов. Недавно как раз обсуждал с коллегами, надо ли или не надо его использовать (в итоге положились на то, что в gcc по умолчанию он не добавляется), и нате.

Оказывается, наличие этого указателя довольно критично для многих профилировщиков. Занятно, что даже в java протекает. При этом какое-то влияние на производительность экономия одного регистра все-таки имеет, но оно меньше 1%, а если больше, то, скорее всего, вызвано проблемами с кэшем и расположением в памяти.

При этом в нормальных обстоятельствах указатель не нужен, а для профилирования есть другие подходы, которым он не нужен.

На маке страдаю от того, что нет нормальной программы для сравнения рандомных кусков текста или папок. На Linux использую Meld, он классный и в нем есть все что нужно, но его порт на Mac M2 работает отстойно: багает с копипастом и крашится. Чисто маковские альтернативы попробовал, одна мразотнее другой (если знаете что-то хорошее, посоветуйте, пожалуйста).

Коллеги подкинули фичу Intellij, о которой не знала даже автор книги про нее (sic!): “Open Blank Diff Window”. Самый быстрый способ, как до нее добраться, это нажать два шифта для меню действий + “OBD” или “ODW”. При этом если надо сравнить что-то с файлом или папкой проекта, то так извращаться не нужно: в контекстом меню файла есть “Compare With…” (Ctrl+D).

Мне пригодилось, когда консольная утилита что-то качала, но то соединение было хреновым.

В bash есть механизм подстановки истории, с помощью которого можно заменить, например, !3 на третью команду из истории. Когда есть Ctrl+r (поиск по истории) и банальные стрелочки — это довольно бесполезно, однако есть шаблон !!, который заменяется предыдущей командой.

!! очень удобен, например, для sudo !! (*блеать.jpg*). И пригодится для повтора:

while [ $? -ne 0 ]; do !!; done

Эта команда будет выполнять предыдущую, пока не будет успешный ответ. Можно завернуть в альяс.

Git — тот еще комбайн, про это полно мемчиков.

Я вообще редко из GUI интерфейса (в IDE) выхожу, потому что консольный — тот еще мрак с точки зрения UX. Но некоторые вещи даже через GUI делать неудобно, поэтому приходится использовать заклинания.

Одно из недавних, которое пригодилось — копирование файлов из другой ветки:

git checkout another_branch -- file_name_or_pattern

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

Занятное исследование про улучшение процессов. Оно довольно старое (2001 год), но актуально до сих пор.

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

Что делать, кроме как повышать осознанность разными способами, особо не раскрывается. В одном примере помогло обучение в игровом формате, а в другом — изменение ментальной модели и просто выделение времени на вещи, давно требующие внимания. Очевидно, снизу так менеджмент не переубедишь :(