Здравствуйте, B0FEE664, Вы писали:
BFE>Ну о каком Reproducible builds вы говорите, если у вас нет тех исходников (в силу изменения истории) из которых можно собрать сделаную ранее сборку?
Очевидно, что никто не переписывает историю мастера или ветки из которой были сделаны релизы, переписывается история рабочей ветки до слияния в мастер.
Похоже, кто-то вообще не понимает, о чем идет разговор...
BFE>Я утрировал, чтобы вы заметили всю нелепость про :
Нелепость это вот это:
Если кто-то в твоё отсутствие собрал exe-шник и отдал подставив в него какой-то другой заголовочный файл, то история будет объяснять, почему так произошло. А когда у вас история не соответствует собранным исполняемым модулям, то как вы будете воспроизводить ошибки?
BFE>Ну вот собрали вы продукт, а потом, по ошибке, переписали историю: BFE>
BFE>1. Или ты никогда не ошибаешься.
BFE>?
Ситуация уровня "мой искходный код съел кот мурзик"... Печально, если у вас такое возможно
BFE>Вообще говоря, контроль версий нужен прежде всего для того, чтобы видеть историю ошибок. Переписывание истории для скрытия ошибк ничем не лучше ведения файла history.
Есть ошибки/коммиты которые точно не нужны:
1. Тривиальные, типа "ой, забыл добавить файл"
2. Ломающие сборку
ИМХО, еще можно избегать "паразитных", типа 'merge origin/master' или "merge pull request 123".
Обсуждаемые вами гипотетические проблемы очень показателены
Здравствуйте, netch80, Вы писали:
N>По умолчанию защита от forced push, да, не включается. Если это нужно, ставится receive.denyNonFastForwards=true в центральной репе.
Хы, забавно звучит в контексте DCVS...
N>Хотя для команды объёмом минимум в 5 человек лучше поставить уже что-то вроде Gerrit, будет сразу peer review, интеграция с CI и прочая.
Т.е. без централизованного веб-костыля нормально организовать работу невозможно. Понятно...
N>Ну и кто не в такой репе поставил core.logAllRefUpdates=always — сам себе ЗБ.
Ну если это насколько нужные опции, то почему они не стоят по умолчанию?
Re[16]: Раз вы тут про гит - почему это убожище победило все
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, netch80, Вы писали:
N>>Это я понял. При чём тут слово master? _NN>Ветка мастера может незащищённой тоже.
Вы писали:
>> Для мастера додумались делать защищённую ветку по умолчанию.
Вот я эту фразу продолжаю не понимать. Кто "додумался", stock Git, админы ваших конкретных реп, или кто?
Если первое, то это точно неправильно. Если второе — то ваши конкретные заморочки в частных случаях как-то не очень важны остальным.
The God is real, unless declared integer.
Re[17]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, AlexRK, Вы писали:
ARK>Тоже всегда удивлял этот маразм.
git bisect не использовали никогда? Историю в больших проектах не приходится смотреть?
Есть ошибки/коммиты которые точно не нужны:
1. Тривиальные, типа "ой, забыл добавить файл"
2. Ломающие сборку
Никакой проблемы переписать локальную историю чтобы избавиться от таких коммитов нет. Минусов у этого нет никаких, а плюсы очевидны.
Re[13]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, netch80, Вы писали:
N>Ещё раз: не чистят историю в уже отправленном хотя бы в репу рабочей группы.
Очень показательно, что они даже не понимают о чем речь
Re[16]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, alex_public, Вы писали:
N>>По умолчанию защита от forced push, да, не включается. Если это нужно, ставится receive.denyNonFastForwards=true в центральной репе. _>Хы, забавно звучит в контексте DCVS...
Абсолютно нормально звучит. Ставишь общую репу — определяй политику.
N>>Хотя для команды объёмом минимум в 5 человек лучше поставить уже что-то вроде Gerrit, будет сразу peer review, интеграция с CI и прочая. _>Т.е. без централизованного веб-костыля нормально организовать работу невозможно. Понятно...
Т.е. начались домыслы на ровном месте. Понятно...
N>>Ну и кто не в такой репе поставил core.logAllRefUpdates=always — сам себе ЗБ. _>Ну если это насколько нужные опции, то почему они не стоят по умолчанию?
Уже сказал: гитовцы слишком хорошо думают о юзерах. Это уже начинает меняться, хотя и слишком медленно.
The God is real, unless declared integer.
Re[17]: Раз вы тут про гит - почему это убожище победило все
Здравствуйте, netch80, Вы писали:
>>> Для мастера додумались делать защищённую ветку по умолчанию.
N>Вот я эту фразу продолжаю не понимать. Кто "додумался", stock Git, админы ваших конкретных реп, или кто? N>Если первое, то это точно неправильно. Если второе — то ваши конкретные заморочки в частных случаях как-то не очень важны остальным.
Разработчики Git серверов как GitHub, GitLab и т.д.
Здравствуйте, Skorodum, Вы писали:
НС>>Зачем их исправлять? Это реальная история изменения кода, она имеет определенную ценность. S>1. Есть мелкие опечатки и ошибки которые никакой ценности не имеют Какая ценность в коммитах типа "ой, забыл закоммитить заголовочный файл вместе с исходником"?
А разве такие вещи исправляют не через amend, без замусоривания истории? )
S>2. "Чистая история" где каждый коммит можно собрать и протестировать сильно облегчает жизнь.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, netch80, Вы писали:
>>>> Для мастера додумались делать защищённую ветку по умолчанию.
N>>Вот я эту фразу продолжаю не понимать. Кто "додумался", stock Git, админы ваших конкретных реп, или кто? N>>Если первое, то это точно неправильно. Если второе — то ваши конкретные заморочки в частных случаях как-то не очень важны остальным.
_NN>Разработчики Git серверов как GitHub, GitLab и т.д.
У меня есть github и bitbucket репы, ни в каком нет умолчательного запрета на force push в master.
The God is real, unless declared integer.
Re[17]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, netch80, Вы писали:
N>>>По умолчанию защита от forced push, да, не включается. Если это нужно, ставится receive.denyNonFastForwards=true в центральной репе. _>>Хы, забавно звучит в контексте DCVS... N>Абсолютно нормально звучит. Ставишь общую репу — определяй политику.
"Общий" и "центральный" репозиторий — это совершенно разные вещи...
N>>>Хотя для команды объёмом минимум в 5 человек лучше поставить уже что-то вроде Gerrit, будет сразу peer review, интеграция с CI и прочая. _>>Т.е. без централизованного веб-костыля нормально организовать работу невозможно. Понятно... N>Т.е. начались домыслы на ровном месте. Понятно...
Где же домыслы? Вполне себе однозначный вывод из твоей фразы, что для команды 5+ лучше ставить централизованную веб-хрень.
N>>>Ну и кто не в такой репе поставил core.logAllRefUpdates=always — сам себе ЗБ. _>>Ну если это насколько нужные опции, то почему они не стоят по умолчанию? N>Уже сказал: гитовцы слишком хорошо думают о юзерах. Это уже начинает меняться, хотя и слишком медленно.
Глупости какие. Если в ПО значение по умолчанию для опции является неподходящим для большинства пользователей, то это однозначный косяк разработчиков этого ПО, а не его пользователей.
Re[12]: Раз вы тут про гит - почему это убожище победило всех?
Отличная статья — показывает, как порождается типичная хаброжвачка и мутит умы.
Если автор коммита, который подвергает его потом ребейзу, не смотрит, что происходит при этом, не проверяет результат на корректность существующими тестами — это всё равно, что он накидал заведомого мусора туда и не проверил, что получилось.
В нормальной среде такое проходит до первого CI теста, на который каждую новую версию надо подавать заново.
The God is real, unless declared integer.
Re[18]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, alex_public, Вы писали:
N>>>>По умолчанию защита от forced push, да, не включается. Если это нужно, ставится receive.denyNonFastForwards=true в центральной репе. _>>>Хы, забавно звучит в контексте DCVS... N>>Абсолютно нормально звучит. Ставишь общую репу — определяй политику. _>"Общий" и "центральный" репозиторий — это совершенно разные вещи...
Тогда определи каждый в твоём понимании.
N>>>>Хотя для команды объёмом минимум в 5 человек лучше поставить уже что-то вроде Gerrit, будет сразу peer review, интеграция с CI и прочая. _>>>Т.е. без централизованного веб-костыля нормально организовать работу невозможно. Понятно... N>>Т.е. начались домыслы на ровном месте. Понятно... _>Где же домыслы? Вполне себе однозначный вывод из твоей фразы, что для команды 5+ лучше ставить централизованную веб-хрень.
Да. Потому что удобство peer review и интеграция с CI. Но это не значит, что нет других средств для того же, которые могут быть совсем не вебовыми.
N>>>>Ну и кто не в такой репе поставил core.logAllRefUpdates=always — сам себе ЗБ. _>>>Ну если это насколько нужные опции, то почему они не стоят по умолчанию? N>>Уже сказал: гитовцы слишком хорошо думают о юзерах. Это уже начинает меняться, хотя и слишком медленно. _>Глупости какие. Если в ПО значение по умолчанию для опции является неподходящим для большинства пользователей, то это однозначный косяк разработчиков этого ПО, а не его пользователей.
Я ж и говорю, что это их косяк
The God is real, unless declared integer.
Re[12]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, alex_public, Вы писали:
_>А разве такие вещи исправляют не через amend, без замусоривания истории? )
amend же только для последнего коммита, а чаще всего надо несколько коммитов в один сжать или переупорядочить.
S>>2. "Чистая история" где каждый коммит можно собрать и протестировать сильно облегчает жизнь. _>"Чистая история" — это типа такого https://habr.com/ru/post/179123/ случая? )))
И что в этом случае особенного? В обоих случаях получили баг, в первом его искать заметно проще, во втором чуть более понятна причина, но если бы автор догадался использовать git blame, то и в первом случае проблем с пониманием не возникло бы
Re[13]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, netch80, Вы писали:
_>>"Чистая история" — это типа такого https://habr.com/ru/post/179123/ случая? ))) N>Отличная статья — показывает, как порождается типичная хаброжвачка и мутит умы. N>Если автор коммита, который подвергает его потом ребейзу, не смотрит, что происходит при этом, не проверяет результат на корректность существующими тестами — это всё равно, что он накидал заведомого мусора туда и не проверил, что получилось. N>В нормальной среде такое проходит до первого CI теста, на который каждую новую версию надо подавать заново.
Люди всегда ошибались и будут продолжать делать это вечно. И CI тут не является панацеей, т.к. тесты пишут опять же люди. В правильном процессе разработки надо всегда предусматривать возможность ошибки, а не бегать с дикими глазами в случае её возникновения.
Так вот, в случае использования классической схемы со слиянием, у нас при возникновение подобной ошибки в репозитории помимо сломанной ревивизии будут:
1. работающая ревизия (в смысле с новым кодом, а не просто что-то древнее)
2. информация о том, кто фиксировал ломающие изменения.
В случае же "чистой истории" сделанной через rebase, у нас в итоге не будет ни того, ни другого. А будет только сломанная ревизия и что-то древнее.
Re[13]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, netch80, Вы писали:
N>Если автор коммита, который подвергает его потом ребейзу, не смотрит, что происходит при этом, не проверяет результат на корректность существующими тестами — это всё равно, что он накидал заведомого мусора туда и не проверил, что получилось. N>В нормальной среде такое проходит до первого CI теста, на который каждую новую версию надо подавать заново.
Справедливости ради, такая ситуация может в жизни возникнуть (не все покрыто тестами, или не было покрыто на момент слияния веток), но сценарий с rebase и "чистой историей" все равно лучше: проблему нашли быстро. Просто забыли сделать git blame в проблемном месте.
Re[19]: Раз вы тут про гит - почему это убожище победило все
Здравствуйте, netch80, Вы писали:
N>У меня есть github и bitbucket репы, ни в каком нет умолчательного запрета на force push в master.
Действительно. Видимо я это делал на автомате, что даже забыл.
Здравствуйте, Skorodum, Вы писали:
S>Справедливости ради, такая ситуация может в жизни возникнуть (не все покрыто тестами, или не было покрыто на момент слияния веток), но сценарий с rebase и "чистой историей" все равно лучше: проблему нашли быстро. Просто забыли сделать git blame в проблемном месте.
Как по git blame можно что-то понять? Я пользуюсь черепахой и это что-то нечитаемое. Есть нормальные ui для этого?
Кодом людям нужно помогать!
Re[14]: Раз вы тут про гит - почему это убожище победило все
Здравствуйте, alex_public, Вы писали:
_>В случае же "чистой истории" сделанной через rebase, у нас в итоге не будет ни того, ни другого. А будет только сломанная ревизия и что-то древнее.
Нарисуй графами то, что ты имеешь в виду, в стиле, например, https://git-scm.com/docs/git-rebase .
С обязательным указанием, что именно из этого для тебя будет "сломанная ревизия", "что-то древнее", где и как будет храниться "информация о том, кто фиксировал ломающие изменения", в общем, всё, что ты упомянул.
Здравствуйте, Skorodum, Вы писали:
BFE>>Ну о каком Reproducible builds вы говорите, если у вас нет тех исходников (в силу изменения истории) из которых можно собрать сделаную ранее сборку? S>Очевидно, что никто не переписывает историю мастера или ветки из которой были сделаны релизы, переписывается история рабочей ветки до слияния в мастер.
Незнаю-незнаю. От людей переписывающих историю рабочей ветки всего можно ожидать.
S>Похоже, кто-то вообще не понимает, о чем идет разговор...
В самом деле...
BFE>>Я утрировал, чтобы вы заметили всю нелепость про : S>Нелепость это вот это: S>
S>Если кто-то в твоё отсутствие собрал exe-шник и отдал подставив в него какой-то другой заголовочный файл, то история будет объяснять, почему так произошло. А когда у вас история не соответствует собранным исполняемым модулям, то как вы будете воспроизводить ошибки?
Конечно нелепость, сотрудники не болеют и не уходят в отпуск.
BFE>>Ну вот собрали вы продукт, а потом, по ошибке, переписали историю: BFE>>
BFE>>1. Или ты никогда не ошибаешься.
BFE>>? S>Ситуация уровня "мой искходный код съел кот мурзик"...
Я правильно понял, что вы никогда не ошибаетесь?
S>Печально, если у вас такое возможно
У нас — это у кого? Я в разных компаниях работал и наблюдал разное...
BFE>>Вообще говоря, контроль версий нужен прежде всего для того, чтобы видеть историю ошибок. Переписывание истории для скрытия ошибк ничем не лучше ведения файла history. S>Есть ошибки/коммиты которые точно не нужны: S>1. Тривиальные, типа "ой, забыл добавить файл"
Да ну? А если между "ой, забыл добавить файл" и когда это заметили прошло 6 месяцев и 500000 коммитов?
S>2. Ломающие сборку
Ломающие сборку для которой платформы из 4-х?
S>ИМХО, еще можно избегать "паразитных", типа 'merge origin/master' или "merge pull request 123". S>Обсуждаемые вами гипотетические проблемы очень показателены
Я стремлюсь учиться на чужих ошибках. Я вообще никогда не использовал эту возможность git и очень надеюсь что никогда не буду использовать. Вот есть такой отзыв пользователя rebase:
Не нужно недооценивать важность сохранения достоверности истории. Rebase — это обман самого себя и своей команды. Вы притворяетесь, что коммиты были написаны сегодня, хотя по факту они написаны вчера на основе другого коммита. Вы вытащили коммиты из исходного контекста, завуалировав то, что произошло в действительности. Вы уверены, что код соберётся? Вы уверены, что сообщения коммитов всё ещё имеют смысл? Вы можете верить в то, что чистите и проясняете историю, но в результате добьётесь прямо противоположного.
