Здравствуйте, B0FEE664, Вы писали:
BFE>Не нужно недооценивать важность сохранения достоверности истории. Rebase — это обман самого себя и своей команды. Вы притворяетесь, что коммиты были написаны сегодня, хотя по факту они написаны вчера на основе другого коммита.
Это не имеет значения. Имеет значение, что в самом коммите, насколько он уместен по отношению к целевой ветке и своему родителю, и насколько вовремя он будет применён и зафиксирован в целевой ветке.
BFE> Вы вытащили коммиты из исходного контекста, завуалировав то, что произошло в действительности.
Что произошло в действительности — видно из сути коммита.
BFE> Вы уверены, что код соберётся?
Там, где есть CI и тесты коммитов — уверен.
Там, где нет — там ещё больше шансов, что сотрудники и без rebase будут лить в репу пургу, которая не будет даже компилироваться.
BFE> Вы уверены, что сообщения коммитов всё ещё имеют смысл?
Да, мы их сравниваем с диффом коммита. То же делают ревьюеры.
BFE>Зачем заниматься самообманом?
Действительно, зачем вы занимаетесь самообманом (и введением в заблуждение читателей этой ветки)?
BFE>Незнаю-незнаю. От людей переписывающих историю рабочей ветки всего можно ожидать.
Точно так же как и от пользователей с шестнадцатиричными никами или с рязанской пропиской.
S>>1. Тривиальные, типа "ой, забыл добавить файл" BFE>Да ну? А если между "ой, забыл добавить файл" и когда это заметили прошло 6 месяцев и 500000 коммитов?
Тогда этот коммит менять не будут, очевидно. Но тогда вопрос, почему он прошёл в таком виде.
The God is real, unless declared integer.
Re[19]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, B0FEE664, Вы писали:
это не я писал, я цитировал BFE>>Не нужно недооценивать важность сохранения достоверности истории. Rebase — это обман самого себя и своей команды. Вы притворяетесь, что коммиты были написаны сегодня, хотя по факту они написаны вчера на основе другого коммита. N>Это не имеет значения. Имеет значение, что в самом коммите, насколько он уместен по отношению к целевой ветке и своему родителю, и насколько вовремя он будет применён и зафиксирован в целевой ветке.
Жуть. Какую задачу вы решаете с помощью этого?
BFE>> Вы уверены, что код соберётся? N>Там, где есть CI и тесты коммитов — уверен.
Что такое "тесты коммитов"?
N>Там, где нет — там ещё больше шансов, что сотрудники и без rebase будут лить в репу пургу, которая не будет даже компилироваться.
так ведь есть же ветки.
BFE>> Вы уверены, что сообщения коммитов всё ещё имеют смысл? N>Да, мы их сравниваем с диффом коммита. То же делают ревьюеры.
Прямо Министерство Правды какое-то.
S>>>1. Тривиальные, типа "ой, забыл добавить файл" BFE>>Да ну? А если между "ой, забыл добавить файл" и когда это заметили прошло 6 месяцев и 500000 коммитов? N>Тогда этот коммит менять не будут, очевидно. Но тогда вопрос, почему он прошёл в таком виде.
Да мало ли. Например потому, что вот такую вот конфигурацию давно никто не собирал.
И каждый день — без права на ошибку...
Re[9]: Раз вы тут про гит - почему это убожище победило всех
Здравствуйте, Skorodum, Вы писали:
НС>>Зато больше подходит к задаче. S>Нет S>Условнй git log v1..v2 удобнее любого трекера
Удобнее для чего? Если для пользователей, то им наплевать и и как правил ты в коде, им важно какие user stories и баги закрыты. А это инфа в трекере куда как в лучшем виде присутствует.
Сидеть же разбирать лог гита и сортировать что куда — это для бедных, когда полноценного трекера нет. А когда он есть — большинство трекеров прекрасно умеют делать release notes автоматично.
НС>>Лучше скажи кто не умеет этого делать. S>Тем более
Это не имеет никакого отношения к тому, что исходно юзкейсы в трекере, а гит это вторичная техническая информация.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[20]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, B0FEE664, Вы писали:
N>>Здравствуйте, B0FEE664, Вы писали: BFE>это не я писал, я цитировал BFE>>>Не нужно недооценивать важность сохранения достоверности истории. Rebase — это обман самого себя и своей команды. Вы притворяетесь, что коммиты были написаны сегодня, хотя по факту они написаны вчера на основе другого коммита. N>>Это не имеет значения. Имеет значение, что в самом коммите, насколько он уместен по отношению к целевой ветке и своему родителю, и насколько вовремя он будет применён и зафиксирован в целевой ветке. BFE>Жуть. Какую задачу вы решаете с помощью этого?
Ту самую, для чего вообще предполагался этот коммит.
BFE>>> Вы уверены, что код соберётся? N>>Там, где есть CI и тесты коммитов — уверен. BFE>Что такое "тесты коммитов"?
Вы не слышали про workflow, когда каждый коммит проверяется как минимум на то, что состояние с этим коммитом компилируется и проходит автотесты? А также, возможно, на стиль кода, покрытие и т.п.?
N>>Там, где нет — там ещё больше шансов, что сотрудники и без rebase будут лить в репу пургу, которая не будет даже компилироваться. BFE>так ведь есть же ветки.
И каким образом ветки смогут обеспечить, что код в них хотя бы компилируется, если не прикручена проверка автотестами?
BFE>>> Вы уверены, что сообщения коммитов всё ещё имеют смысл? N>>Да, мы их сравниваем с диффом коммита. То же делают ревьюеры. BFE>Прямо Министерство Правды какое-то.
Что означало это странное сравнение?
S>>>>1. Тривиальные, типа "ой, забыл добавить файл" BFE>>>Да ну? А если между "ой, забыл добавить файл" и когда это заметили прошло 6 месяцев и 500000 коммитов? N>>Тогда этот коммит менять не будут, очевидно. Но тогда вопрос, почему он прошёл в таком виде. BFE>Да мало ли. Например потому, что вот такую вот конфигурацию давно никто не собирал.
Значит, автотесты неполные. Да, это чаще именно так, чем что они тестируют вообще всё. Ну так ничто не идеально.
The God is real, unless declared integer.
Re[11]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, Skorodum, Вы писали:
НС>>Зачем их исправлять? Это реальная история изменения кода, она имеет определенную ценность. S>1. Есть мелкие опечатки и ошибки которые никакой ценности не имеют
Имеют. Потому что исправление этих мелких ошибок порой что то ломает.
S> Какая ценность в коммитах типа "ой, забыл закоммитить заголовочный файл вместе с исходником"?
Понятно почему предыдущий коммит поломал билд и когда билд починили.
S>2. "Чистая история" где каждый коммит можно собрать и протестировать сильно облегчает жизнь.
В каком месте?
S>Твои аргументы сейчас похожи на аргументы нелюбителей вещей типа RAII в соседней теме про C++
А ваши аргументы — на голую вкусовщину.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[19]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, netch80, Вы писали:
_>>"Общий" и "центральный" репозиторий — это совершенно разные вещи... N>Тогда определи каждый в твоём понимании.
Общий — это любой с которым синхронизируются из более чем одного места. Т.е. это может быть хоть мой личный репозиторий на NAS'е, с которым я синхронизируюсь с рабочей станции и с ноута. Хотя с учётом возможности синхронизации репозиториев через файлы (присылаемые например по почте), это вообще не тривиальный вопрос, как определить общий репозиторий. )))
А вот центральный — это более понятное явление, имеющее корни из централизованной разработки. Это такой репозиторий, из которого все члены команды достают последние изменения, в который засылают свои и из которого код берётся для тестов, релизов и т.п.
_>>Где же домыслы? Вполне себе однозначный вывод из твоей фразы, что для команды 5+ лучше ставить централизованную веб-хрень. N>Да. Потому что удобство peer review и интеграция с CI. Но это не значит, что нет других средств для того же, которые могут быть совсем не вебовыми.
Например? Я серьёзно интересуюсь, потому как для ведения задач у нас используется самописный трекер, как раз для целей избежать централизации (которая неизбежна при веб-решение). А вот для всего остального про не веб решения я особо не слышал...
Re[13]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, Skorodum, Вы писали:
_>>А разве такие вещи исправляют не через amend, без замусоривания истории? ) S>amend же только для последнего коммита, а чаще всего надо несколько коммитов в один сжать или переупорядочить.
И какое отношение "надо несколько коммитов в один сжать или переупорядочить" имеет к "Есть мелкие опечатки и ошибки которые никакой ценности не имеют Какая ценность в коммитах типа "ой, забыл закоммитить заголовочный файл вместе с исходником"?"?
Т.е. вот последнее я полностью понимаю и одобряю. Но это как раз решается через amend. А вот сжатие и переупорядочивание коммитов через amend конечно же не сделаешь, но я и не вижу ни единой причины для подобных изменений истории.
S>>>2. "Чистая история" где каждый коммит можно собрать и протестировать сильно облегчает жизнь. _>>"Чистая история" — это типа такого https://habr.com/ru/post/179123/ случая? ))) S>И что в этом случае особенного? В обоих случаях получили баг, в первом его искать заметно проще, во втором чуть более понятна причина, но если бы автор догадался использовать git blame, то и в первом случае проблем с пониманием не возникло бы
Во втором случае у нас как минимум есть работающая ревизия (с новым кодом) в репозитории.
Re[15]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, netch80, Вы писали:
_>>В случае же "чистой истории" сделанной через rebase, у нас в итоге не будет ни того, ни другого. А будет только сломанная ревизия и что-то древнее. N>Нарисуй графами то, что ты имеешь в виду, в стиле, например, <https://git-scm.com/docs/git-rebase>. N>С обязательным указанием, что именно из этого для тебя будет "сломанная ревизия", "что-то древнее", где и как будет храниться "информация о том, кто фиксировал ломающие изменения", в общем, всё, что ты упомянул.
Зачем мне что-то рисовать, если все картинки (собственно там вообще скрины!) были в той статье с Хабра? Ну если тебе там почему-то сложно, то посмотри на конкретный пример репозитория из той статьи: https://github.com/rabovik/RebaseVSMergeExample/tree/rebase. В ветке rebase ревизия "2+3=5" содержит в себе некорректный код. А в ветке merge ревизия "2+3=5" содержит вполне себе корректный код, аналогов которому в ветке rebase просто нет.
Ну и да, если ты не понял, то "древнее" — это первая ревизия в данном примере, а "сломанная ревизия" — это последняя ревизия (в каждой из веток).
Re[18]: Раз вы тут про гит - почему это убожище победило всех?
BFE>Не нужно недооценивать важность сохранения достоверности истории. Rebase — это обман самого себя и своей команды. Вы притворяетесь, что коммиты были написаны сегодня, хотя по факту они написаны вчера на основе другого коммита. Вы вытащили коммиты из исходного контекста, завуалировав то, что произошло в действительности. Вы уверены, что код соберётся? Вы уверены, что сообщения коммитов всё ещё имеют смысл? Вы можете верить в то, что чистите и проясняете историю, но в результате добьётесь прямо противоположного.
Думаю, тщеславие. Rebase — чисто эстетическая операция. Чистенькая история приятна нам как разработчикам, но это не может быть оправдано ни с технической точки зрения, ни с точки зрения функциональности.
Re[10]: Раз вы тут про гит - почему это убожище победило всех
Здравствуйте, netch80, Вы писали:
N>А на каком коммите будет у вас основана эта "ветка с отдельным хотфиксом"? N>Если master, v1 и v2 каждый получил свои специфические изменения, а хотфикс универсален для них (неизменная или мало изменившаяся часть кода), то вы не найдёте такого общего базового коммита, и мерж превратится в ад. N>А вот черипик для таких условий — идеален.
Ну да, фиксится обычно релизная ветка, а потом коммит переносится в мастер. Тут черри-пик нужен. Но речь шла о чекауте отдельного коммита, что эта странная команда переключает ветку, либо чекаутит определённый коммит, либо восстанавливает изменённые файлы.
Re[16]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, alex_public, Вы писали:
_>Зачем мне что-то рисовать, если все картинки (собственно там вообще скрины!) были в той статье с Хабра? Ну если тебе там почему-то сложно, то посмотри на конкретный пример репозитория из той статьи: https://github.com/rabovik/RebaseVSMergeExample/tree/rebase. В ветке rebase ревизия "2+3=5" содержит в себе некорректный код. А в ветке merge ревизия "2+3=5" содержит вполне себе корректный код, аналогов которому в ветке rebase просто нет.
Код там абсолютно одинаковый Разница именно в истории.
Здравствуйте, Sharov, Вы писали:
S>Как по git blame можно что-то понять? Я пользуюсь черепахой и это что-то нечитаемое. Есть нормальные ui для этого?
Я использую встроенный в QtCreator, выглядит отлично можно перейти на любой коммит, могу завтра какой-нибудь публичный репозиторий показать если интересно.
Черепаху давно не использовал, но раньше она пыталась мимикрировать под SVN, поэтому все было как-то нестандартно для git.
Re[17]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, Skorodum, Вы писали:
_>>Зачем мне что-то рисовать, если все картинки (собственно там вообще скрины!) были в той статье с Хабра? Ну если тебе там почему-то сложно, то посмотри на конкретный пример репозитория из той статьи: https://github.com/rabovik/RebaseVSMergeExample/tree/rebase. В ветке rebase ревизия "2+3=5" содержит в себе некорректный код. А в ветке merge ревизия "2+3=5" содержит вполне себе корректный код, аналогов которому в ветке rebase просто нет. S>Код там абсолютно одинаковый Разница именно в истории.
Здравствуйте, alex_public, Вы писали:
_>Нет разницы в коде? )))
После мерджа — нет. И нет, ветка с merge не содржит в себе рабочий код и изменения "Пети" и "Васи" одновременно.
Здравствуйте, Skorodum, Вы писали:
_>>Нет разницы в коде? ))) S>После мерджа — нет. И нет, ветка с merge не содржит в себе рабочий код и изменения "Пети" и "Васи" одновременно.
Естественно не содержит, т.к. это невозможно в принципе — данные два изменения несовместимы между собой. Однако в ветке merge они хотя бы оба в наличие, пусть и по отдельности. А в ветке rebase нет даже этого...
Re[16]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, netch80, Вы писали:
N>>По умолчанию защита от forced push, да, не включается. Если это нужно, ставится receive.denyNonFastForwards=true в центральной репе.
_>Хы, забавно звучит в контексте DCVS...
В корпоративной работе не так много людей, которые реально пользуются удобствами распределённой системы, и код не проходит через центральный репозиторй.
Как раз наоборот, удобно иметь центральный сервер, чтобы всё проходило через него и все видели работу других.
Так можно и код ревью сделать и подсказать если еть какие-то проблемы.
Вообще не всем легко даётся понимание распределённой системы и зачем нужны эти приседания.
По факту SVN с рабочей локальной историей и нормальными ветками покрыл бы все потребности и было бы проще объяснить людям как этим пользоваться.
N>>Хотя для команды объёмом минимум в 5 человек лучше поставить уже что-то вроде Gerrit, будет сразу peer review, интеграция с CI и прочая.
_>Т.е. без централизованного веб-костыля нормально организовать работу невозможно. Понятно...
Можно и без веба конечно, но да без специального сервера не обойьтись, иначе запросто можно убить всю истрию.
N>>Ну и кто не в такой репе поставил core.logAllRefUpdates=always — сам себе ЗБ.
_>Ну если это насколько нужные опции, то почему они не стоят по умолчанию?
Так оно и еть по умолчанию
core.logAllRefUpdates
Enable the reflog. Updates to a ref <ref> is logged to the file "$GIT_DIR/logs/<ref>", by appending the new and old SHA-1, the date/time and the reason of the update, but only when the file exists. If this configuration variable is set to true, missing "$GIT_DIR/logs/<ref>" file is automatically created for branch heads (i.e. under refs/heads/), remote refs (i.e. under refs/remotes/), note refs (i.e. under refs/notes/), and the symbolic ref HEAD. If it is set to always, then a missing reflog is automatically created for any ref under refs/.
This information can be used to determine what commit was the tip of a branch "2 days ago".
This value is true by default in a repository that has a working directory associated with it, and false by default in a bare repository.
Здравствуйте, Hobbes, Вы писали:
H>Ну да, фиксится обычно релизная ветка, а потом коммит переносится в мастер. Тут черри-пик нужен. Но речь шла о чекауте отдельного коммита, что эта странная команда переключает ветку, либо чекаутит определённый коммит, либо восстанавливает изменённые файлы.
Функционал разных действий прямо сейчас разносится — в последних версиях выделены команды restore и switch.
Но ты спрашивал не о смысле команды checkout, а о смысле действия чекаута отдельного коммита. Так вот, смысл достаточно заметный — получить состояние отдельного конкретного коммита независимо от того, является он сейчас головой какой-то ветки или нет. Например, по нему может строиться конкретный релиз или билд, он может проверяться bisectʼом (или вручную) на какое-то свойство, он может просто анализироваться и т.п.
И для комбинированного действия есть смысл. Вот буквально вчера: коллега говорит "Этот П (ушедший 2 года назад) какого-то хрена снёс тестовую прокладку S, с которой отлично работалось, и поставил тупой самопал на Go. Такое впечатление, что ему хотелось просто поиграться с новым языком. Надо восстановить." Можно сделать revert на старый коммит и поиметь кучу проблем с мержем, а можно просто вытащить два файла хэндлера для S. Последнее — как раз в самом общем синтаксисе — `git checkout $revision $path`.
The God is real, unless declared integer.
Re[20]: Раз вы тут про гит - почему это убожище победило всех?
Здравствуйте, alex_public, Вы писали:
_>Естественно не содержит, т.к. это невозможно в принципе — данные два изменения несовместимы между собой.
Ну т.е. проблема тут есть при любом сценарии использовании гита.
_>А в ветке rebase нет даже этого...
Зато дойти до проблемного коммита можно куда быстрее и с меньшей головной болью. Далее если использовать git blame никакой проблемы понять, что так произошло нет.
Разница именно в истории.
