История изменений
Исправление gaylord, (текущая версия) :
угу, но это не то же самое, что каждый коммит помечать. И между прочим в fossil ветки реализованые как раз через тэги.
Ну это очень странный тейк. То есть писать простыню описывающую изменение – не страшно, а добавить тег – страшно? Кажется это что-то из области ОКР.
нет, ручных манипуляций тут как раз меньше
У тебя UUID появился, конечно же их стало больше
И что? как мне поможет необязательный комментарий
Во-первых это дефолтное сообщение, во-вторых у тебя и ветки необязательные, можно всем дружно в мастер лить. Совсем-то с ума наверное сходить не надо?
неопределенного формата в задаче автоматизировано извлечь информацию из истории?
Во-первых это well-known формат, во-вторых почему бы и нет? Мы же на теги как-то полагаемся, а там, о ужас, имена неопределенного формата. А от них, меджу прочим, git-describe версию генерирует.
И как я уже отметил ранее, хорошо, если этот merge commit вообще присутствует. А то ведь, могут предложить смотреть коммент к pull-реквесту, который вообще не является частью git истории.
Опять же, я могу сделать один коммит Initial commit и все присылаемые мне изменения туда ребейзить. И будет у меня репозиторий с одним коммитом. А ещё можно изменения на десять тысяч строк мержить с описанием «small fixes». Повторюсь, что совсем с ума сходить не надо.
Так в том и дело, что ты предлагаешь каждой команде разработчиков решать её самостоятельно, вместо того, чтобы предоставить встроенные инструменты.
Так они предоставлены уже. GitHub, GitLab и прочее тем или иным образом работают с информацией из коммит мессенджей. Это работает даже через почту в ядре, все довольны.
Но работать-то надо, поэтому работа ведется, как есть. В лучшем случае ведутся какие-то вялотекущие обсуждения типа «а зачем нам merge commit, это лишний артефакт». Со всеми вытекающими последствиями для истории в VCS.
А эти последствия они вообще реальны для этих людей? У них есть задача искать по ветке точки слияния?
Исправление gaylord, :
угу, но это не то же самое, что каждый коммит помечать. И между прочим в fossil ветки реализованые как раз через тэги.
Ну это очень странный тейк. То есть писать простыню описывающую изменение – не страшно, а добавить тег – страшно? Кажется это что-то из области ОКР.
нет, ручных манипуляций тут как раз меньше
У тебя UUID появился, конечно же их стало больше
И что? как мне поможет необязательный комментарий
Во-первых это дефолтное сообщение, во-вторых у тебя и ветки необязательные, можно всем дружно в мастер лить. Совсем-то с ума наверное сходить не надо?
неопределенного формата в задаче автоматизировано извлечь информацию из истории?
Во-первых это well-known формат, во-вторых почему бы и нет? Мы же на теги как-то полагаемся, а там, о ужас, имена неопределенного формата. А от них, меджу прочим, git-describe версию генерирует.
И как я уже отметил ранее, хорошо, если этот merge commit вообще присутствует. А то ведь, могут предложить смотреть коммент к pull-реквесту, который вообще не является частью git истории.
Опять же, я могу сделать один коммит Initial commit и все присылаемые мне изменения туда ребейзить. И будет у меня репозиторий с одним коммитом. Повторюсь, что совсем с ума сходить не надо.
Так в том и дело, что ты предлагаешь каждой команде разработчиков решать её самостоятельно, вместо того, чтобы предоставить встроенные инструменты.
Так они предоставлены уже. GitHub, GitLab и прочее тем или иным образом работают с информацией из коммит мессенджей. Это работает даже через почту в ядре, все довольны.
Но работать-то надо, поэтому работа ведется, как есть. В лучшем случае ведутся какие-то вялотекущие обсуждения типа «а зачем нам merge commit, это лишний артефакт». Со всеми вытекающими последствиями для истории в VCS.
А эти последствия они вообще реальны для этих людей? У них есть задача искать по ветке точки слияния?
Исходная версия gaylord, :
угу, но это не то же самое, что каждый коммит помечать. И между прочим в fossil ветки реализованые как раз через тэги.
Ну это очень странный тейк. То есть писать простыню описывающую изменение – не страшно, а добавить тег – страшно? Кажется это что-то из области ОКР.
нет, ручных манипуляций тут как раз меньше
У тебя UUID появился, конечно же их стало больше
И что? как мне поможет необязательный комментарий
Во-первых это дефолтное сообщение, во-вторых у тебя и ветки необязательные, можно всем дружно в мастер лить. Совсем-то с ума наверное сходить не надо?
неопределенного формата в задаче автоматизировано извлечь информацию из истории?
Во-первых это well-known формат, во-вторых почему бы и нет? Мы же на теги как-то полагаемся, а там, о ужас, имена неопределенного формата.
И как я уже отметил ранее, хорошо, если этот merge commit вообще присутствует. А то ведь, могут предложить смотреть коммент к pull-реквесту, который вообще не является частью git истории.
Опять же, я могу сделать один коммит Initial commit и все присылаемые мне изменения туда ребейзить. И будет у меня репозиторий с одним коммитом. Повторюсь, что совсем с ума сходить не надо.
Так в том и дело, что ты предлагаешь каждой команде разработчиков решать её самостоятельно, вместо того, чтобы предоставить встроенные инструменты.
Так они предоставлены уже. GitHub, GitLab и прочее тем или иным образом работают с информацией из коммит мессенджей. Это работает даже через почту в ядре, все довольны.
Но работать-то надо, поэтому работа ведется, как есть. В лучшем случае ведутся какие-то вялотекущие обсуждения типа «а зачем нам merge commit, это лишний артефакт». Со всеми вытекающими последствиями для истории в VCS.
А эти последствия они вообще реальны для этих людей? У них есть задача искать по ветке точки слияния?