Комментарии 34
Когда битбакет помахал ручкой меркуриалу, я на баше сделал скрипт, который в рабочей копии hg-репозитория откатился к первому коммиту, инициализировал гит репозиторий тут же, а потом начал скакать по истории коммитов и делал гитовые коммиты. Топорно, не сохранились метки времени, долго, но меня устроило :)
...опция 5 - остаться на Bitbucket, сконвертировать свои Mercurial-репозитории на git, используя hg-git. Ну и наверняка есть еще куча других вариантов.
В свое время столкнулся абсолютно с той же проблемой, написал скрипт, конвертящий все репозитории на аккаунте в git, и даже запилил статью на Хабре. Обидно, что из-за таких вот действий хостингов репозиториев куча разработчиков тратит драгоценное жизненное время, велосипедя конверторы репозиториев. Ну и за Mercurial обидно - все-таки некоторые вещи там сделаны более человечно, чем в git
А зачем вообще Bitbucket без Mercurial'а, если есть GitHub? ИМХО поскольку есть возможность безболезненно мигрировать, то Bitbucket'у грош цена теперь.
Bitbucket -- это же Atlassian и Jira
Семантический поиск в Битбакете есть (правда, я не уверен, что его кто-то использует). И цена ниже.
Интересно мнение уважаемых коллег - какой есть практический смысл перенесения в новый рабочий репозиторий всех полуархивных коммитов фактически забытого проекта за много лет?
Ну, конечно, кроме желания сидя у камина полистать альбом с пожелтевшими фотографиями :)
как раз потому, что проект (полу)забытый, перенос истории играет огромную роль. Коммиты могут подсказать, как что менялось, почему. В каком контексте.
Честно говоря, вопрос из разряда "а как иначе-то?". Просто снашоту текущего состояния - грош цена. Он ничего не расскажет, непонятно будет, как всё пришло к этому состоянию.
Не могли бы привести примеры того, как и в чем вам помог просмотр коммита 5-летней давности? Чисто мне для понимания вашего процесса разработки.
В чем для вас ценность "долгого пути", если есть работающий код? Мне не понятно.
Или что вы вообще разрабатываете?
p.s.
просто я пользователь с "пожизненной" лицензией еще самого первого Битбакета, доатлассиановского, но вот лазить по 15-летней истории фактически ни разу не приходилось.
вопрос из серии "назовите 7 предметов цвета сирени".
элементарно, в комментариях к коммитам или в предыдущих версиях можно найти ответы по алгоритмическим составляющим. не все очевидно в финальном вылизанном коде. также, репозиториями пользуются не только разработчики, но и научные работники. 10 лет — это смешной срок для научной группы. Концепция постоянного продвижения.
в целом, мой опыт будет не совсем релевантен.
в репозиториях, с которым я имею дело, хранится не только код, но и масса документов в текстовом и LaTeX форматах.
и не только документы, но и книги, сверстанные в LaTeX, сотни книг.
А книги иногда переиздают и иногда требуется поднятие истории принятых тех или иных решений.
На самом деле, совершенно неважно чем я занимаюсь. Это уже какие то персоналии пошли, но им тут не место.
Обнаружена проблема, найдено решение.
И вероятно, что у x% пользователей битбакета такая проблема тоже может возникнуть.
В целом, исходный вопрос кажется праздным. Тем, у кого этой проблемы нет и решение это не требуется.
Нужно быть очень умным человеком, чтобы по структуре коммитов (которых может быть и с десяток на одну фичу) реконструировать мысль программиста.
Почему вы не используете комментарии в коде? Они специально для этого сделаны.
Почему вы не используете комментарии в коде?
Разве вы все продукты пишете единолично? Заведение репозитория и его последующее наполнение — два различных процесса.
Может это вопрос к 100500 людям, которые приложили руку к репозиторию за все время его существования?
"Мой репозиторий" — не означает единоначалия, это форма такая. Читать как "репозиторий, к которому иногда приходится обращаться и который надо сохранить".
Если вы пишете продукты не единолично и у вас хаотично ведет себя команда, то вы и по комментам ничего не поймете. Это утопия красивая. В жизни не получилось ни разу ни у кого.
Почему любой четкий технический тезис уходит на личности?
Исходный вопрос прост до безобразия.
"Есть репозиторий, в облаке его реплики уже нет. Что можно сделать?"
При чем здесь команда, жизненный цикл продукта, IQ сотрудников и прочая ерунда? И хранится там, например, далеко не только код, см. выше.
Лично мне вообще наплевать на вопрос "можно или нельзя восстановить по комментариям 10-ти летней давности". Это одна из форм коллективной enterprise прокрастинации.
Возникнет проблема — будем разбираться. Не возникнет — еще лучше. Но лучше все оставить, если есть возможность, чем просто выкинуть в корзину. Тем более, что денег не просит.
Сугубо прагматичный подход.
Где я сделал хоть какой-то вывод о конкретно вашей личности?
__
"Есть репозиторий, в облаке его реплики уже нет. Что можно сделать?"
Что можно сделать для какой цели? Чтобы была реплика и в облаке? Тогда:
git remote add origin <url> && git push origin
Только к чему этот вопрос?
__
"Лично мне вообще наплевать на можно или нельзя восстановить по комментариям 10-ти летней давности."
Вы заметили, что весь тред только этому и посвящен? Если вам плевать, то что вы пытаете доказать конкретно в этом треде?
- неважно в каком треде, почтовая нотификация к публикации всплывает по всему.
- чему именно он посвящен? здесь вопросы к публикации вроде как.
- считаю, что свою часть выполнил, дал развернутые пояснения на вопросы к публикации. обсуждать значимость комментариев неинтересно.
Давайте так: вы можете себя, конечно, считать ответственным за все комменты под вашим постом, но мне тяжело разговаривать с человеком, который не в курсе контекста треда (тред != основной пост) под которым пишет и обьясняет это видом нотификаций.
Тред про восстановление бизнес-логики из коммитов. Ни про что другое. Как будет что сказать на эту тему - буду вас слушать.
контекст смешной. "какова ценность коммитов и комментариев к ним"
между любой парой коммитов можно сделать diff и увидеть изменения. комментарии к коммиту интересны, но вторичны.
а также увидеть части кода, которые были удалены по той или иной причине, например, изменилось поведение внешней библиотеки.
обязательства компании по поддержке развернутого много лет назад продукта требуют бережного отношения к коду. иначе на саппорте по SLA можно в трубу вылететь.
если контекст ответственности за внедренное решение Вам не знаком, то не надо меня слушать, я всеми руками за.
"комментарии к коммиту интересны, но вторичны."
Комментарии к коду, а не к коммиту.
А комментарии к коммиту умеют правильно писать около 2-3% программистов всего.
__
"а также увидеть части кода, которые были удалены по той или иной причине, например, изменилось поведение внешней библиотеки."
Искать "что у нас там изменилось" - очень популярный метод среди новичков. Только он продиктован неумением траблшутить и читать собственный код.
Человек, который контролирует код, включая код импортированных 3rd-party библиотек, не нуждается в ретроспективе.
Кстати, поиск "что изменилось" обычно не имеет никаких ограничений по времени. Может через минуту повезти, а может и никогда. Потому что не вы контролируете код, а код контролирует вас.
Не стоит брать одно удобное решение и строить на нем выводы — типичное манипуляторство.
Смотрите всю комбинаторику. Даже в двух размерностях мы уже имеем 4 комбинации:
Новичок — свой код
Новичок — чужой код
Эксперт — свой код
Эксперт — чужой код
Даже в такой простой модели утверждение про "неумение траблшутить" вызывает вопрос: "а почему только один квадрант рассмотрен?".
И ведь правда, в каждом квадрате будут свои резоны.
Про комментарии и иже с ними лучше читать классиков, Кнута, Макконелла,… Чего на хабре спорить — пустое это.
Вот теперь я увидел ключевые слова "научная группа" и ваши мотивы стали более понятными.
Во многих местах хорошей практикой (а иногда и обязательной) является указание ссылки на тикет в той же Jira в комментарии к коммиту. Это помогает понять не только сам код, но и причины его написания.
мемуары писать :)
"Вечером, в павильоне, который находился в огромном парке родового поместья, барон, уютно устроившись в кресле и закурив любимую трубку, собирал жаждущих послушать необыкновенные рассказы и начинал “вспоминать”..."
а почему сразу в такой радикальной трактовке? часто проекты завершают развитие и находятся потом в эксплуатации не один десяток лет.
ПО на фортране и коболе — типичный пример.
и без сохранения репозитория эта задача резко вырастает в трудозатратах.
А у вас есть какие-то реальные примеры использования коммитов многолетней давности в полузабытых проектах, в которые не коммитили уже года три (судя по тому, сколько времени Битбакет предупреждал пользователей о том, что сворачивает Меркуриал)?
Но хотелось бы именно реальных примеров из практики.
да выше крыши.
почти весь телеком.
инновационность давно оттуда ушла.
однако же все продолжают звонки совершать и трафик потреблять.
а обслуживают это все системы, написанные в конце 20-го, начале 21-го века.
и иногда их приходится чуть подправлять под новые обстоятельства.
многие компании исчезли или были поглощены, многие разработчики ушли, некоторые в лучший из миров.
а код, отдельные куски которого писали в т.ч. индусы, продолжает обслуживать абонентов.
Для проекта история имеет огромное значение. Вот есть строка непонятная строка кода - по истории можно понять кто и когда, под какую задачу делал, становится ясно можно ли её менять и как именно можно. Выручало неоднократно.
А в целом это вопрос гигиены - врядли кто сильно задумывается каждый раз почему нужно помыть руки по приходу домой, и зачем переходить дорогу на зелёный свет. Если нет веской причины дропать историю, её стоит сохранять
Так уж случилось, что у меня остался ряд репозиториев на Mercurial, которые захостил на Bitbucket много лет назад
Дак Bitbucket начал активно предупреждать ещё в 2019, а апреле 2020 удалил все hg репозитории.
В чём смысл этой статьи на июль 2021?
Практически все пояснено в тексте и комментариях.
Так получилось. И это нормально для полу архивных проектов. Такие кейсы не единичные.
Облачные системы постоянно находятся в движении и трансформации. Есть важные, используемые повседневно. Есть вторичные, до которых руки не доходят на ежедневный мониторинг.
Можно тоже задам вопрос? В чем смысл задавать вопрос "в чем смысл?" Задающему такой вопрос тема фиолетова и никакого смысла не несет вообще.
Праздное любопытство? Желание показать превосходство? Иные мотивы?
Тоже столкнулся с этим когда битбакет отказался от меркуриала. Без проблем перенес этим скриптов кучу репо на гитхаб с сохранением истории и кириллицей.
https://github.com/frej/fast-export
Уходим с Mercurial на Git