История изменений

Я не очень понимаю суть предложения. Ты хочешь хранить ВСЕ ветки что когда-либо существовали? Но это же лютая помойка будет. Есть проекты где по тысяче тикетов в релиз.

Да, вполне себе вариант. Вам вообще-то не нужно знать о существовании этих веток и их количестве (как не нужно знать обо всех коммитах в истории). Плюс соглашении о наименовании веток, если таки нужно найти/отфильтровать ветку по названию.

И все это ради того чтобы три слова в коммит не написать?

Именно. Это должен быть встроенный (конечно настраиваемый, отключаемый) механизм, а не ручные манипуляции. VCS должна снимать нагрузку с пользователя и уменьшать роль человеческого фактора а не наоборот.

Не говоря уже о том что жто ломает тот flow, что есть в ядре.

Да и хрен с ним :-). Мы же сейчас не о linux kernel рассуждаем, а о VCS в принципе.

Если это как-то и делать, то вероятно схоже с тем, как это сделано сейчас. В коммит пишутся теги Signed-off-by, Bug, Fixes и прочее. Наверное можно было бы сделать это не частью коммита, а, например, отдельной метой, обновляемой независимо.

Угу, какие-то метаданные.

Но стоит ли этого добавленная сложность ваще неясно.

А Вы выйдите за рамки git и посмотрите, как это уже сделано в других VCS (opensource, про коммерческие даже не говорим): См. https://www.sqlite.org/whynotgit.html#git_does_not_track_historical_branch_names

Там ссылка на историю в git и в fossil. В fossil истории присутствует имя ветки, точка ветвления, вливания из upstream в ветку и точка слияния ветки в upstream.

Я не очень понимаю суть предложения. Ты хочешь хранить ВСЕ ветки что когда-либо существовали? Но это же лютая помойка будет. Есть проекты где по тысяче тикетов в релиз.

Да, вполне себе вариант. Вам вообще-то не нужно знать о существовании этих веток и их количестве (как не нужно знать обо всех коммитах в истории). Плюс соглашении о наименовании веток, если таки нужно найти/отфильтровать ветку по названию.

И все это ради того чтобы три слова в коммит не написать?

Именно. Это должен быть встроенный (конечно настраиваемый, отключаемый) механизм, а не ручные манипуляции. VCS должна снимать нагрузку с пользователя и уменьшать роль человеческого фактора а не наоборот.

Не говоря уже о том что жто ломает тот flow, что есть в ядре.

Да и хрен с ним :-). Мы же сейчас не о linux kernel рассуждаем, а о VCS в принципе.

Если это как-то и делать, то вероятно схоже с тем, как это сделано сейчас. В коммит пишутся теги Signed-off-by, Bug, Fixes и прочее. Наверное можно было бы сделать это не частью коммита, а, например, отдельной метой, обновляемой независимо.

Угу, какие-то метаданные.

Но стоит ли этого добавленная сложность ваще неясно.

А Вы выйдите за рамки git и посмотрите, как это уже сделано в других VCS (opensource, про коммерческие даже не говорим): См. https://www.sqlite.org/whynotgit.html#git_does_not_track_historical_branch_names https://www.sqlite.org/whynotgit.html

Там ссылка на историю в git и в fossil. В fossil истории присутствует имя ветки, точка ветвления, вливания из upstream в ветку и точка слияния ветки в upstream.