Возьмите проект с, скажем, исполняемым источником в главном репозитории M и зависимыми библиотеками в нескольких подмодулях S1, S2 и т. Д. Принято решение, что некоторый код в исполняемом файле должен быть перенесен в библиотеку в подмодуле S1.сделать его общедоступным для других проектов.Мы разветвляем и главный репозиторий, и подмодуль, и шаг 1 процесса миграции состоит в том, чтобы просто переместить N файлов из каталога в M в конкретный каталог (с разными путями) в S1.Наивный способ сделать это - просто собрать файлы из M, переместить их в новый каталог в S1, перейти в подмодуль cd и добавить их.Проблема, конечно, в том, что вся история потеряна для этих файлов.Это не большая проблема, потому что я не думаю, например, что pull-merge будет отслеживать изменения из файлов в M в их новый дом в S1, но было бы неплохо иметь возможность восстанавливать как изменения изменения, которыебыли сделаны файлы, чтобы приспособиться к их новому расположению и другим необходимым изменениям, связанным с рефакторингом.
Так вот мой вопрос: есть ли лучший способ выполнить миграцию файлов с M на S1, чем простой rm-и-добавить так, чтобы хотя бы история файлов сохранялась.Конечно, если бы он был внутри M, просто использовали бы git-mv.Я видел некоторую формулу для перемещения файлов между произвольными репозиториями, но A, я считаю, что им почти невозможно следовать, и B, я надеялся, что, возможно, управляемые отношения между main и submodule сделают его более легким или более элегантным для выполнения.Если ответ заключается в том, что для этих целей M и S1 являются просто двумя произвольными различными репозиториями, возможно, кто-то здесь мог бы изложить шаги с объяснением так, что это лучше, чем я видел в других местах.На самом деле это задача, которую я сейчас рассматриваю, так что любая соответствующая обратная связь будет принята.
Редактировать: было разумно предположить, что это дублирование Git: перемещение файлов в существующуюподмодуль .Кажется, что это правда, и меня не удивляет, что это уже поднималось ранее, но ответ довольно лаконичен для читателя с довольно элементарным пониманием git.Я надеялся на разбивку шагов с более полным описанием задействованных команд.
Edit2: мне приходит в голову, что причина - ответ для предполагаемого дублирования (и для других подобных вопросов и ответов)не работают для меня в два раза.С одной стороны, потребовалось прочитать их все пару раз, чтобы понять, что делается, просто потому, что мне нужно углубить мою модель происходящего в git.Это на мне.Но, сделав это, и теперь, понимая, что происходит с этими подходами разделения и слияния, я понимаю, что проблема, которую я пытаюсь решить, проходит немного глубже - настолько глубоко, что фактически я начинаю понимать, что, вероятно,единорог, которого мерзавец не может доставить.
БЧru у вас есть монолитное хранилище - нет подмодулей, вы можете переместить файл с помощью git mv, и это даст системе больше информации, чем простое удаление из одного местоположения и добавление в другое.Он сохраняет историю, но я считаю, что он также позволяет git отслеживать изменения, внесенные в перемещенные файлы, независимо от того, где они находятся в других локальных репозиториях.Поэтому, если я перемещаю свои файлы в ветке, а другие изменяют файлы по своему собственному представлению о файлах, фиксируют и помещают эти изменения и объединяют их с основной веткой, то я считаю, что у git достаточно учетной информации, что, когда я извлекаю эти изменения, они сливаются с файлами в их новом расположении в моем представлении хранилища.Это гораздо более значительная добавочная стоимость (на мой взгляд), чем просто сохранение истории.Если я удаляю файлы из основного репозитория и добавляю их в подмодуль, у них не будет истории в их новом местоположении, но история из их жизни в старом местоположении все равно будет извлечена через «призраки» удаленных файлов.Неудобно, но не катастрофично.Но если бы был способ управлять изменениями из представлений других разработчиков и направлять их на файлы, которые существуют в субмодуле, это было бы удивительно.Настолько удивительно, что кажется за пределами того, что мог сделать git.Подводя итог, я думаю, что я искал волшебное «git mv», которое могло бы работать через репозитории, и теперь, когда я думаю об этом, я сомневаюсь, что такая вещь существует.