Нужно изменить один коммит в истории. Что вы сделаете?

я очень рад твоей скорости чтения и огорчен твоим уровнем понимания, так что давай ещё раз ответ на твой вопрос содержится в двух моих предыдущих коментариях.

зачастую не всегда можно сделать правильную логическую группировку до окончания работы. А когда ты закончил и собераешься поделиться своей работой с сообществом, то изволь сделать историю идеальной

Не с сообществом, а с Линусом. В проектах, с которыми я имел дело, этим чистодрочевом не занимаются.

Понятно, демагогия. Всего доброго.

vurdalak ★★★★★ (30.11.2014 23:24:17) УО, даже не трать время, (Скончался академик Эдуард Кругляков)

ты не изменился.

любой пул реквест должен содержать последовательную историю, во всяком случае сделал так, а потом исправил там не должно быть (только это если не 2 дополнительные фичи, которые по каким-либо причинам нужно включить в один реквест). Вообще подход с неисправлением истории приводит к тому, что люди нифига не коммитят, или коммитят серию «сделал-исправил-исправил», или гении, но я ни одного гения за свою жизнь не встречал (по делам, а не заявлениям о себе).

<вброс>а я сегодня делал git push -f на гитхаб</вброс>

если не в мастер то не считается

5. Ничего не делать — история должна быть неприкосновенной.

Бывают такие ситуации, что в историю попадают данные, нежелательные для чужих глаз. Реализация бекдура например, или непросоленный хеш системного пароля, который нельзя менять из-за обратной совместимости.

И вспоминают об этом не сразу.

Поэтому должна быть возможность изменить историю.

Это не оправдание.

Как только будет замечено, что история менялась (даже в намёках или попытках) - доверие к подобным проектам начинает стремится к нулю.

Нужны достаточно веские причины, чтобы менять историю. Это напоминает местами попытки затирания следов в кидопедии...

Подписанные ключи не захотят подчиняться смене истории.

любой пул реквест должен

Кому должен? Вам в воскресной школе так сказали?

новый коммит с необходимыми изменениями.

Кстати ты обломишься о подписанный коммит

Как только будет замечено, что история менялась (даже в намёках или попытках) - доверие к подобным проектам начинает стремится к нулю.

В GIT хранят не только исходный код.

Но и конфиги системы, тот же /etc. Из которых в паблик может попасть то, что не должно быть в паблике.

какой школе?! воспитательница в детском саду!

«у» это видимо «упоротый». А что такое «о»?

И да, благодарю за ссылку. Теперь я вспомнил, почему игнорил leave. Надо писать более точные комментарии, а то с годами забывается, что насокращал :(

Все правильно говоришь. Есть стабильная master, нужны изменения — создаешь новую, в нее коммитешь на каждом этапе разработки. При завершении тестирования мержишь с master и коммитишь все это дело контрольным коммитом. В результате получаешь хронолорическую цепочку стабильных коммитов твоего проекта.

Не с сообществом, а с Линусом.

Это правило хорошего тона во многих проектах. Чем бОльшее дерьмище по форме или контенту предлагать внедрить в апстрим тем меньше вероятность что в нём будет кто-то копаться.

Ну я вообще немного не это имел в виду. У меня это работает так: делаешь кусок изменений (условно «одну фичу»), коммитишь. Если фича очень большая и её можно разбить на подфичи, но по одной их коммитить нельзя (всё сломается, пока не будет завершена), то делаешь ветку и работаешь в ней, а потом этот же набор коммитов пушишь в мастер. Ведь если ты месяц изменений зальёшь одним коммитом, то фиг потом по истории разберёшься, какое изменение к какой «части фичи» относилось и что могло сломать.

Проблемы хранения credentials-информации в общем дереве кода решаемы.

Если что-то утекло - нужно смотреть по ситуации, но это не оправдывает необходимость смены истории. Это совсем не нормальная ситуация и это мягко сказано.

Как правило в dangling blobs всё еще будет там. Это как войти в реку два раза.

Лучше ориентироваться на то, что всё в проекте максимально прозрачно и открыто. Дешевле выйдет и доверия больше. Или будешь как m$ у которого каждый квартал что-то случайно утекает в сеть.

Если будут ветки- разберешься. Делать коммиты в мастер ни есть хорошо, это не svn, где нет понятия локальных коммитов. Я, к примеру, делаю коммиты перед обедом и в конце дня, вне зависимости от состояния проекта (есстественно, доведя ло логического завершения определенный участок кода), плюс коммиты при успешном добавлении некоторых маленьких фич. В конце дня делается git push . Работай в мастере проблемы при таком подходе очевидны

Видимо, это зависит от проекта. В тех с которыми я работал принято, что ты завершил логическую фичу, сделал коммит и кинул его на ревью. Когда ревью прошёл, пушишь в мастер. В личных проектах обычно стараюсь делать ветки, но обычно забиваю, так как для стабильных версий ставлю теги, а пытающиеся собрать из мастера ССЗБ :3

Нужно изменить один коммит в истории. Что вы сделаете?

Сделаю коммит с исправлением. Мы же не в 1984, чтобы историю править задним числом.

return std::move (ret);

Убивать! Дальше не смотрел

Не скажу что у меня какие то сложные задачи, но обычно их решение занимает 40-80 часов, потому потеря кода 2х дневной работы, к примеру, критична. Потому, предпочитаю сохраняться на уровне рабочего каталога, а этапы логического завершения уже пушшить в репозиторий.

Господа, если вам так зудит делать все через задницу менять историю коммитов, то, может быть в консерватории что-то исправить не извращаться, а просто отказаться от VCS? Миллион проблем ведь снимет, и, с таким ебанутым подходом к разработке, ни одной новой не добавит.

или непросоленный хеш системного пароля, который нельзя менять из-за обратной совместимости.

Если ты просрал пароль у тебя два варианта: Либо тебе насрать на безопасность и парится нет смысла, либо ты его меняешь во всех своих обратных совместимостях безо всяких отговорок. Ну либо добавляешь другой механизм для обеспечения безопасности. Полумеров тут нет.

А что не так? Разве что многословно — тут согласен.

В чём дело?

так делать нельзя

В каком смысле «нельзя»? UB или неэффективно?

А что не так? Разве что многословно — тут согласен.

Ты просто не понимаешь как работает move. Ну и man RVO.

Как работает move, я прекрасно понимаю: заставляет компилятор выбирать T::T (T&&), если оно есть.

RVO

Что, RVO не сработает, если сделать std::move()?

очень много слов и очень сложно на плюсах это выглядит.

просто бросай так делать, я бы такие коммиты не принимал. Это не имеет смысла и приносит только баги. Особенно если речь о последней строке метода

убери эту фигню, и прогони профайлером. Увидишь, что ничего не изменилось. Ололо.

Практически всегда делаю: git commit --fixup && git rebase --autosqash. Часто получается несколько fixup-коммитов в локальной ветке до момента её чистки.

Я уже понял, что «не принимал бы». Может, расскажешь, почему не имеет смысла и приносит только баги?

Поражаюсь количеству неадекватов в треде. Человек спросил конкретный вопрос про правку коммита на локалхосте, а ему рассказывают какие-то отдалённые вещи, что заливать исправленную историю в абстрактный проект плохо. Не fast-forward-коммиты это вообще-то основополагающая фича распределённых систем контроля версий, когда в своём репозитории ты можешь бесконечно вылизывать историю коммитов.

Умственно отсталый.

Да, ты такой.

Что, «hg так не умеет -> не нужно»?

потому что, очевидно, копирования и так не произойдет в инструкции return.

Неочевидно: RVO (а точнее NRVO) — всего лишь оптимизация, совершенно необязательная.

Вопрос у меня следующий: std::move() предотвращает NRVO (если все остальные требования выполнены и компилятор его умеет)?

покажи мне компилятор, который не умеет RVO. Даже gcc для Эльбруса умеет RVO

История коммитов служит конкретной практической цели — логически группировать изменения.

Вот в том то и проблема, что гит застрял где-то посередине между «историей как хроникой изменений» и «историей как списком рабочих состояний проекта, сгрупированных логически».

Вот бы было хорошо, если бы сделали новую VCS, где были бы сразу оба подхода, «история» и «интерпретация истории». История была бы неприкосновенна, а интерпретацию можно было бы редактировать сколько угодно.

У меня на ветках постоянные ребейзы с форсами :)

В hg тоже так можно сделать, но не из коробки. Намёк на то, что если бы был на это спрос, этот плагин бы уже запилили в апстрим :)

Вот жесть........

Ты наверное подпись какую-нибудь не добавил и теперь перфекционизмом занимаешься?

Неочевидно: RVO (а точнее NRVO) — всего лишь оптимизация, совершенно необязательная.

Да, но компилятор имеет право использовать перемещение и без явного указания. А вот явный вызов std::move запрещает RVO/NRVO.

Да и зачем писать лишний бессмысленный код?

Пока не зашел в тред, был уверен, что речь о каком-то историческом коммите. Например, в котором был создан heartbleed или что-то настолько же значимое. И как могла бы измениться новейшая история мира, если бы этот коммит можно было изменить.

Разочарован.

А вот явный вызов std::move запрещает RVO/NRVO.

Можно про это поподробнее? Это по стандарту так?

потому что, очевидно, копирования и так не произойдет в инструкции return.

Очевидно это зависит от тела ф-ии. Если объект сам по себе не локальный, то будет копирование и от return std::move() будет профит, или без этого код не соберётся.