LINUX.ORG.RU

инструменты для облагораживания репы в меркуриале

 , ,


0

2

есть приватная репа в меркуриале (в том смысле что никто снаружи не клонировал, а если клонировал — то пофиг на это), внутри в основном скрипты и данные для них

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

работа разовая (то есть не требуется регулярно (и значит полуавтоматически) ее производить в результате каких-то будущих изменений в репе, с которой моя репа была склонирована, но возможность делать эту работу полуавтоматически — полезный бонус)

итак, задачи:

1. затирание паролей (я понимаю это как задачи 2,3,4)

2. вообще замены по регекспу в файле и всех его потомках

3. правка описания коммита

4. удаление коммита (где фактически был затерт пароль — в будущем этот коммит не нужен)

5. добавление коммита, где файл перенесен в другую директорию, и изменение всех последующих коммитов под это

6. разбиение 1 коммита на 2 коммита произвольным образом (это видимо сводится к задачам 7,8,9)

7. разбиение коммита на несколько коммитов, каждый из которых затрагивает только 1 файл

8. разбиение коммита на несколько коммитов, каждый из которых затрагивает только 1 строчку (ну или около того)

9. слияние нескольких коммитов в 1 коммит

тут можно было бы придумать задачи

10. раскидывание репы в набор директорий с номерами коммитов, описаниями и графом зависимостей

11. обратная сборка репы из директорий

чтобы все задачи 1...9 делать над файловой системой, но это видимо неверный подход?

теперь попробую провести систематичность:

А. есть операции, которые не меняют графа коммитов, а меняют только содержимое файлов, директорий, или описания коммита

В. есть операции, которые меняют граф коммитов, и не меняют содержимое файлов/директорий/описаний там, где граф коммитов неизменен

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

для В желательны графические (мышекликательные) тулзы, хотя можно и командно-строчные

дополнительный бонус — возможность этими тулзами работать и с гит-ом

в целом, желательно такое же удобство работы с этим хозяйством, как с файловой системой (хотя у нас тут граф, и все сложнее)

ну и сам вопрос: правильный список задач и тулзы для работы со всем этим; ссылки на конкретные главы книг/документации/вопросы so приветствуются

UPDATE: если какая-то тулза делает не все задачи, а только часть, то ее вполне можно предложить

Для большинства задач готовых инструментов нет, но, наверное, всё это можно набыдлить через hg convert.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

тут даже хочется именно систему, типа как для работы с файлами достаточно mkdir, rm, mv, cp, ln (и replace/awk/perl для ковыряния содержимого) — и ты типа все умеешь, так и тут

что касается hg convert — я не вижу в списке форматов «набор директорий, соответствующих коммитам с файлами метаданных»; ты предлагаешь конвертировать из меркуриала в меркуриал?

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

тут даже хочется именно систему типа как для работы с файлами достаточно mkdir, rm, mv, cp, ln

Да не вопрос - hg cp, hg mv, hg rm. Вопрос в том, как поверх результата применения этих команд (отредактированного ченджсета) накатывать уже имеющиеся ченджсеты. В принципе, можно через evolve или даже rebase, но будет много ручного труда.

ты предлагаешь конвертировать из меркуриала в меркуриал?

Естественно. Это вообще штатный способ преобразования репозитория.

хорошо, а для каких задач есть готовые инструменты?

Посмотри https://www.mercurial-scm.org/wiki/EvolveExtension Наверное, к нему можно свести всё, что ты хочешь, но мышетыкательного интерфейса нет.

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 2)
Ответ на: комментарий от tailgunner

Да не вопрос - hg cp, hg mv, hg rm.

я знаю про эти команды, речь шла о другом — о наборе команд для редактирования графа коммитов (если упрощенно считать репу графом коммитов) по аналогии с набором команд для «редактирования» фс

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

речь шла о наборе команд для редактирования графа коммитов (если упрощенно считать репу графом коммитов)

Внезапно, hg commit, hg merge и hg rebase. Ну и полный набор evolve.

по аналогии с набором команд для «редактирования» фс

Сова, глобус.

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Сова, глобус.

и фс, и репа — ориентированный ациклический граф с метаданными в вершинах (правда репа все же чуть посложнее)

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

Сова, глобус.

и фс, и репа — ориентированный ациклический граф с метаданными в вершинах

В отличие от ФС, репа иммутабельна, поскольку насквозь провязана криптохешами.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Внезапно, hg commit, hg merge и hg rebase.

они, как я понимаю, ориентированы почти исключительно на добавление к репе — это примерно как текстовый редактор умел бы только дописывать в конец файла (а редактировать только последнюю строку), и не более того; а изредка надо именно редактировать в середине файла, причем и удалять

Ну и полный набор evolve.

посмотрю

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от tailgunner

В отличие от ФС, репа иммутабельна, поскольку насквозь провязана криптохешами.

я согласен сделать копию, после изготовления которой пересчитать криптохэши

в бд тоже есть ограничения целостности, и обычно есть режим их отключить, загрузить данные, включить ограничения целостности — то же можно было бы и здесь (правда тут еще и проще может быть)

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

они, как я понимаю, ориентированы почти исключительно на добавление к репе — это примерно как текстовый редактор умел бы только дописывать в конец файла, и все, а изредка надо именно редактировать в середине, причем и удалять

Если при редактировании графа придерживаться только commit, merge и rebase, процесс редактирования сводится к созданию новых вершин (фактически подграфа) и последующему клонированию только этого подграфа через hg clone -r. Хотя rebase умеет удалять ветки со старого места, я не уверен, что для твоих задач этого хватит.

tailgunner ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

эээ... я ж вроде все объяснил?

ну например в репе есть пароль, а нужен почти клон репы, но с затертым паролем; еще неправильно сделанные коммиты — т.е. несколько коммитов в одном; или наоборот, один коммит получился размазанным по нескольким коммитам (все по недосмотру)

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

В чем необходимость выполнять все эти операции и действия?

Присоединяюсь к вопросу, зачем это всё? Ну кроме паролей может быть ещё.

orm-i-auga ★★★★★ ()
Ответ на: комментарий от orm-i-auga

неправильно сделанные коммиты

несколько коммитов в одном

Наверное, раз коммитер сделал несколько отдельных коммитов, так и было задумано. Т.е. с его стороны всё правильно. )

orm-i-auga ★★★★★ ()
Ответ на: комментарий от orm-i-auga

Присоединяюсь к вопросу, зачем это всё?

Например, работа сделана наспех и хочется ее облагородить (оставим в стороне вопрс, не является ли такое облагораживание бессмысленным перфекционизмом).

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

В отличие от ФС, репа иммутабельна, поскольку насквозь провязана криптохешами.

фс тоже бывает иммутабельна

тогда иммутабельную фс можно скопировать на мутабельную, мутабельную «отредактировать» путем mkdir/rm/mv/cp/ln, затем залит полученную фс на уже вторую иммутабельную фс

я согласен и на такой вариант с репой (т.е. нужна промежуточная, насквозь мутабельная репа)

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от orm-i-auga

Наверное, раз коммитер сделал несколько отдельных коммитов, так и было задумано. Т.е. с его стороны всё правильно. )

конечно нет — в результате первого коммита че-то заглючило, пришлось глюк исправлять вторым коммитом, а во время второго коммита там были еще добавлены фичи, про которые я забыл, что они добавлены

эт же скрипты, все правится наживую и почти всегда без тестов

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 3)
Ответ на: комментарий от tailgunner

(оставим в стороне вопрс, не является ли такое облагораживание бессмысленным перфекционизмом).

не оставим

там были кое-какие скрипты, которые я счел deprecated и удалил (не из истории конечно, а hg remove) — теперь я хочу их вернуть обратно, но в директорию deprecated — пусть там валяются, иногда они нужны

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

В отличие от ФС, репа иммутабельна, поскольку насквозь провязана криптохешами.

фс тоже бывает иммутабельна

Может быть. Я просто таких не знаю. Ну а ФС, провязанных криптохешами, я совсем не знаю.

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

Это всё должно исправляться по ходу дела, через mq или evolve. Редактирование уже готовой репы себя не оправдывает.

(оставим в стороне вопрс, не является ли такое облагораживание бессмысленным перфекционизмом).

не оставим

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

Возможно, это проблема преждевременного пуша, т.к. несложные правки коммита без проблем делаются через --amend.

скрипты

Хотя, если здесь hg использовался как средство доставки до места (сервера), может и есть смысл.

orm-i-auga ★★★★★ ()
Ответ на: комментарий от tailgunner

ы? вот SquashFS иммутабельна же?

Это всё должно исправляться по ходу дела, через mq или evolve. Редактирование уже готовой репы себя не оправдывает.

по ходу дела это просто можно не заметить, да и некогда

кроме того, для этого нужно переключаться на совсем другую деятельность — на борьбу с dvcs

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

раз в квартал можно — тем более, это еще и обзор того, что там в репе происходит

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

вот SquashFS иммутабельна же?

Ну тогда любая ФС на CDROM явлется иммутабельной.

переключаться на совсем другую деятельность — на борьбу с dvcs

Нужно освоить средства, имеющиеся в DVCS. Например, вышеупомянутые mq и evolve.

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

раз в квартал можно

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)

Если перенесёшь всё в git (зачем, кстати, у тебя этот тег?), то сможешь воспользоваться git-filter-branch (это пункты 1, 2, 3, 4 автоматической обработкой скриптом) и git-rebase (ручная работа с остальными пунктами, нужен ключик -i для интерактивного режима)

mashina ★★★★★ ()
Последнее исправление: mashina (всего исправлений: 1)
Ответ на: комментарий от mashina

зачем, кстати, у тебя этот тег?

потому что вопрос по сути dvcs-agnostic (и то, что реально репа в меркуриале, дело почти не меняет)

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

а редактирование фс как? всякие там mv и ln тоже деццтво?

Деццтво - это не понимать, что репа и ФС - разные вещи.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Исправлять надо именно по ходу дела, пока проблема и решение находятся в горячем кэше.

как раз исправление будет сопровождаться подъемом забытой инфы о репе в кэш, что полезно; а по ходу дела времени нифига нет, и даже запустить графический инструмент под это дело и то время займет, а тем более сидеть ваять необычные (для меня) команды для dvcs

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

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от tailgunner

по-моему тебе ясно, что я разницу понимаю

на самом деле все вопрос опыта — на перфекционизм в виде «редактирования» ФС можно потратить неограниченное количество времени, а потом приходит понимание, когда оно нужно, а когда нет

и еще разница в том, что для фс есть набор «mkdir, rm, mv, cp, ln, awk» который де-факто стандарт, а для dvcs нет, и поэтому в dvcs времени можно угробить на порядки больше

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 2)
Ответ на: комментарий от orm-i-auga

Возможно, это проблема преждевременного пуша, т.к. несложные правки коммита без проблем делаются через --amend.

--amend же вроде только к последнему коммиту, не?

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от tailgunner

Принципиальная ошибка. Исправлять надо именно по ходу дела, пока проблема и решение находятся в горячем кэше.

ммм... если бы можно было легко редактировать, то возможен был бы такой вариант работы: быстренько делаю несколько коммитов с почти пустым описанием (чтобы зафиксировать ситуацию), а затем, допустим в конце дня или может недели, вдумчиво их комментирую (по диффу все видно) — но не через квартал конечно; mq тут как-нибудь поможет?

но даже и в таком случае может выясниться, что в еще более будущем описание надо бы поменять

и бывают случаи, например, когда баг пофикшен весьма давно, а сегодня я делаю коммит, где удаляю строчку комментария (или выхлопа программы) с напоминанием о баге в совсем другом месте — это однозначно надо перенести в тот старый коммит, тут и думать нечего

при этом по диффу видно, что произошло, и искать тот старый коммит что сейчас, что через квартал одинаково трудно (или легко); а вот профит от того, что через квартал я занимаюсь этой работой массово, а сейчас — однократно, будет заметен

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 4)
Ответ на: комментарий от tailgunner

Принципиальная ошибка. Исправлять надо именно по ходу дела, пока проблема и решение находятся в горячем кэше.

наконец, работу вида «объединить старый коммит с исправлением бага с новым коммитом, удаляющим упоминание о баге в другом месте» можно было бы поручить менее квалифицированному помощнику — пусть он работает на подхвате и экономит время более квалифицированного программиста

www_linux_org_ru ★★★★★ ()

затирание паролей

удаление коммита (где фактически был затерт пароль — в будущем этот коммит не нужен)

из чужих бэкапов не удалить, поздно пить боржоми

anonymous ()
Ответ на: комментарий от www_linux_org_ru

Да, я это про случай

в результате первого коммита че-то заглючило, пришлось глюк исправлять вторым коммитом

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

orm-i-auga ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

и бывают случаи, например, когда баг пофикшен весьма давно, а сегодня я делаю коммит, где удаляю строчку комментария (или выхлопа программы) с напоминанием о баге в совсем другом месте — это однозначно надо перенести в тот старый коммит, тут и думать нечего

После пуша? Однозначно неправильно. Ты же сломаешь всем всё. Ну а до пуша уж каждый волен делать что хочет.

orm-i-auga ★★★★★ ()

Я бы склонировал это все в гит, сделал 1-9 встроенными средствами, и запушил бы обратно

annulen ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

по-моему тебе ясно, что я разницу понимаю

Если бы понимал - не возвращался бы к этой аналогии (которая даже формально неверна - ФС не является DAG).

В остальном - been there, done that. Никакого профита. И кстати - ты же понимаешь, что каждый отредактированный коммит нужно проверять так же, как новый? И, возможно, последующие за ним коммиты?

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

которая даже формально неверна - ФС не является DAG

ты про . и .. ?

это всего лишь деталь реализации DAG, которая ускоряет поиск противоположного конца ребра, и не меняет сути

или про симлинки? они могут указывать куда угодно, но симлинки только с большой натяжкой можно назвать частью фс, поскольку за их целостностью никто не следит и они могут быть битые — симлинк это вообще почти короткий текстовый файл

или, допустим, не любой DAG является фс, если у нас hard link not allowed for directory

но то что ты написал это совсем странно

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от tailgunner

В остальном - been there, done that. Никакого профита.

путеводитель по подводным граблям — это, по-моему, самое интересное чтиво; я слушаю

И кстати - ты же понимаешь, что каждый отредактированный коммит нужно проверять так же, как новый? И, возможно, последующие за ним коммиты?

что в нем надо проверять?

если в dvcs будет храниться инфа о том, что «отредактированный коммит» является например суммой двух других коммитов, то проверять его и не особо надо (в том смысле, что дифф нового коммита это конкатенация диффов двух старых)

или в более сложном случае пропали коммиты A,B,C,D,E но появились F,G,H так что A+Е+C+В+D=F+H+G, тоже проверять не особо много надо

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от tailgunner

если хочется точно разобраться, то надо видимо устроить инъективное отображение графа ФС в DAG, которое бы переводило вершины в вершины, ребра в ребра, и сохраняло инцидентность (ну то есть что мы ожидаем от отображения графов) ... ну или че-то в этом духе

вот попробуй сделай инъективное отображение произвольного графа в DAG, которое бы переводило вершины в вершины, ребра в ребра и сохраняло инцидентность — по-моему, у тебя ничего не выйдет, а вот с графом ФС вполне получается... вроде...

проблема в том, что не любой DAG представим в виде ФС, а то бы я предъявил биекцию

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от tailgunner

по-моему, проще всего рассмотреть ФС, где разрешены хардлинки на директории, и ссылок вида .. не одна штука, а несколько — ровно по одной штуке на каждую родительскую директорию

и тут я тебе предъявлю биекцию таких графов на DAG, что должно доказать, что они в общем-то и есть DAG, несмотря на циклы

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от annulen

Я бы склонировал это все в гит, сделал 1-9 встроенными средствами, и запушил бы обратно

кстати, это, вероятно, самый простой способ.

waker ★★★★★ ()
Ответ на: комментарий от littlechris

сначала хотел предложить встроенный плагин histedit, но там нет split. поэтому таки да, только evolve

если histedit предоставляет более простой интерфейс, хотя и только для части задач, то можно предложить и его

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 2)
Ответ на: комментарий от tailgunner

hg cp, hg mv, hg rm

а хочется что-то типа hg batch rm, т.е.

hg update 1234 # 1234  это *старая* ревизия
hg batch rm passwords1.txt # удаляет passwords1.txt во *всех* зависимых ревизиях
hg batch replace '$password2="secret";' '$password2=get_password_2();' file1.pl file2.pl file3.pl # заменяет текст во *всех* зависимых ревизиях
hg batch commit

понятно, что тут возможно еще и конфликты разрешать придется

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от annulen

Я бы склонировал это все в гит, сделал 1-9 встроенными средствами, и запушил бы обратно

для расширения кругозора вполне пригодный вариант; как называются встроенные средства гита для этого? waker

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от orm-i-auga

После пуша? Однозначно неправильно. Ты же сломаешь всем всё. Ну а до пуша уж каждый волен делать что хочет.

это, по-моему, недоработка dvcs (и hg evolve предлагает этому одно из приемлемых решений — секретные и драфтовые ревизии)

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

man git-rebase, man git-filter-branch. возможно есть и другие.

waker ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.