Опубликован выпуск проекта git-bug 0.9, развивающего систему отслеживания ошибок, хранящую информацию об проблемах и комментарии в форме объектов в репозитории Git. По аналогии с изменениями в исходном коде инструментарий git-bug позволяет помещать информацию об отслеживаемых ошибках во внешние репозитории, используя операцию push, а также извлекать данные из внешнего в локальный репозиторий операцией pull. Код проекта написан на языке Go и распространяется под лицензией GPLv3...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63248
Звучит, как потенциально неплохой новый бэкенд для Emacs Forge. =)
Чем бы дитё не тешилось - лишь бы не вешалось.
Какие ломающие фичи тут есть, которых нет в той же багзилле?
Кроме "децентрализованности".
Децентрализованность - супер-мега-киллер-фича, одной ее достаточно in so far as проектам в последнее время приходится часто переезжать с одного провайдера к другому, в особенности там, где переезд вызван внешними геополитическими причинами.
Возможность склонировать github issues себе в локальную репу, не?Когда сносят проект с гитхаба — утеря issues одна из самых болезненных вещей.
А почему нельзя с таким же успехом уже в имеющийся репо складывать баги, доку, дезигны и всякие разные тесты от QA и автоматедQA?
Чтобы не захламлять историю патчей. Обсуждение бага запросто может скатиться во флуд. Даже если оно не скатилось, там могут быть десятки репортов от разных людей, и всё это происходит асинхронно от наложения патчей на основной проект.Можно выкрутиться конечно, можно завести отдельную ветку, которая не будет трогать исходные тексты или ещё что-то, которая будет вносить изменения только в описания багов. Такую ветку легко можно отребазить на HEAD, не проблема. Но чем это принципиально отличается от отдельного репа?
Кто-нибудь пользовался git notes? Что с ними полезного можно сделать?
Если для комментариев сделать отдеььный репозитарий в git?
Куда Яжфинн смотрит? Git дополнения на Go пишут, а не на сях. Git-LFS тоже на Go написан.