VCS пошли куда-то не туда
Я более 20 лет использую системы контроля версий, начинал ещё с RCS, сейчас такую наверное и не помнят. Но вот это для меня звучит полной тарабарщиной:
Squashing commits via the command line using "git merge - squash" is just another time consuming step. That's why we have an option to allow Git users to automatically squash commits in feature ( Read more... )
Squashing commits via the command line using "git merge - squash" is just another time consuming step. That's why we have an option to allow Git users to automatically squash commits in feature ( Read more... )
Нет, в публичном репозитории НИКОГДА нельзя менять историю. Если точнее, можно менять историю только у тех коммитов, про которые ты уверен, что их никто себе не скачал, ну или ты точно знаешь, что скачавший их готов к тому, что история может меняться, и знает, как чинить последствия. При повторном пулле из репозитория с подчищенной историей происходят разные неприятные штуки, поэтому так лучше не делать.
Изменение истории происходит не в момент пуша, а до него. Пуш идет уже на измененной истории.
В некотором роде - это и есть синтез. Да, при таком подходе теряется полная равноправность всех репозиторев, часть из них становится выделенными (публичными), где нужно соблюдать этикет и нельзя делать некоторые операции, но это выделение чисто логическое, с точки зрения техники это по-прежнему такой же удаленный репозиторий.
Reply
А если я не хочу модифицировать историю в своём личном репозитории? Если я хочу непременно сохранить все свои борения, ошибки и матюки, но вынужден прятать их от попадания в публичный репозиторий, то как я должен действовать?
Нет, в публичном репозитории НИКОГДА нельзя менять историю. Если точнее, можно менять историю только у тех коммитов,
Значит будут менять, соблазн "подчистить летописи" всегда слишком велик.
Reply
Если ты не хочешь менять историю, то можешь сделать еще одну ветку, туда слить изменения, потом на ней уже отредактировать историю и запушить ее. Собственно, git merge --squash, которым ты возмущаешься - это ровно оно.
"Значит будут менять, соблазн "подчистить летописи" всегда слишком велик."
1. Это очень хорошо видно (у всех, кто успел слить себе старые изменения, поломается нормальная работа), и следы, по которым все можно восстановить, остаются.
2. Хозяин репозитория может запретить менять историю в своем репозитории.
3. В централизованных системах такая возможность тоже есть, svndumpfilter. например.
Reply
Звучит неплохо и довольно безобидно. Типа черновик и чистовик. Почему тогда ты говоришь, что эти инструменты "довольно хрупкие и легко ломаются, требуется изрядная дисциплина при их использовании"?
3. В централизованных системах такая возможность тоже есть, svndumpfilter. например.
Это всё же другое, на живом репозитории это сделать нельзя, только при клонировании репозиториев. Вот в CVS иногда делали repocopy по живому, но это не от хорошей жизни, а из-за отсутствия версионирования каталогов.
Reply
Потому что при этом теряется связь между исходными коммитами и новыми, с измененной историей. С точки зрения VCS - это совершенно не связанные между собой изменения. Вся связь - у тебя в голове (в коммит логах). Соответственно, теряется защита от, например, повторного применения какого-то изменения. Средства для поддержки такого образа действий есть, но они появились поздно и прикручены несколько сбоку. Но это мое личное мнение, я неуверенно себя в таком варианте чувствую, много команд живет с таким воркфлоу, и неплохо.
Это всё же другое, на живом репозитории это сделать нельзя, только при клонировании репозиториев.
Ну никто не мешает склонировать репозиторий и подменить им исходный. Я, может, скажу крамольную, вещь, но если у тебя есть доступ к файлам репозитория на диске, то ты там можешь наворотить чего угодно, и никто тебе не сможет помешать. Собственно, повторюсь, если в гите отредактировать историю в публичном репозитории, то если хоть кто-то до редактирования успел эту историю стащить к себе (pull сделать), то он:
- сразу увидит, что было сделано что-то необычное
- сможет восстановить (у себя, локально) состояние до этого редактирования.
Так что смысл редактирования как "подчистить летописи" теряется подчистую.
А если никто до исправления в репозиторий заглянуть не успел, то и какая разница.
Reply
О. А вот это плохо. Наверное против этого я и возмущаюсь. Я бы тоже неуверенно чувствовал.
Ну никто не мешает склонировать репозиторий и подменить им исходный. Я, может, скажу крамольную, вещь, но если у тебя есть доступ к файлам репозитория на диске, то ты там можешь наворотить чего угодно,
Почему я и предлагаю не рассматривать эти действия в нашем разговоре. Давай обсуждать только то, что можно сделать штатным клиентом hg, git и пр. (типа rebase, histedit и пр).
А если никто до исправления в репозиторий заглянуть не успел, то и какая разница.
А вот тут я не согласен. Мне больше нравится, когда история считается indelible (как любят выражаться в документации к hg. Хотя и в hg есть расширения для всех этих возмутительных надругательств над историей).
Reply
Скажем так. Есть несколько возможных сценариев черновик-чистовик
1. Черновик - он почти идеален, и в момент пуша его надо только подновить с учетом того, что в репозитории что-то успело произойти с момента содания ветки-черновика.
2. Черновик неидеален, но перед тем, как запушить изменения, ты черновик редактируешь или копируешь в чистовик, и дальше старый черновик не используешь, если нужна дальнейшая доработка - создается новый черновик на основании запушенного чистовика, и все по кругу.
3. Черновик неидеален, но ты его не выбрасываешь, на основе его копии делаешь чистовик, а затем продолжаешь разработку в старом черновике, и в какой-то момент делаешь новый чистовик на основе нового черновика, часть которого уже один раз ушла в репозиторий.
Сценарии 1-2 поддерживаются хорошо, с ними проблем нет. Проблемы могут быть только с 3 сценарием, когда фактически у тебя растет 2 ветки с одними и теми же изменениями, но по-разному упакованными в набор коммитов. Тут сложно, хотя средства тоже есть.
Давай обсуждать только то, что можно сделать штатным клиентом hg, git и пр. (типа rebase, histedit и пр).
Это некоторое лукавство. repocopy в CVS - это штатно или нет? Если какой-то возможности в старой системе штатно нет, и не появится, т.к. по факту развитие остановилось, как-то странно считать это преимуществом. Но окей, давай будем только про штатные средства.
Мне больше нравится, когда история считается indelible (как любят выражаться в документации к hg. Хотя и в hg есть расширения для всех этих возмутительных надругательств над историей).
Тут вопрос отношения, а не техники. Как по-моему, если я не могу сделать приватный репозиторий с грязной историей, а потом удобно ее привести к приличному виду перед передачей на публику (сделать патч и приложить его отдельным коммитом можно всегда, но это неудобно), это изрядно уменьшает набор потенциальных сценариев использования. Tools, not policy, не? В конце концов, если тебе редактирование истории так поперек горла, есть хуки, которыми можно все тебя не устраивающее запретить.
Кстати, технически после надругательства над историей вся старая версия в репозитории остается, и есть штатные средства ее увидеть. Правда, т.к. это получается "изолированная" ветка, никак не связанная с основной историей, через некоторое время ее таки уберет garbage collector. Я как-то после экспериментов занимался таким восстановлением репозитория, это вполне посильная вещь.
Reply
Нештатно конечно. Средствами /usr/local/bin/cvs этого никак не сделать.
Reply
Leave a comment