2013-09-12 3 views
3

У меня необычная потребность, и мне интересно, сможет ли Git заполнить ее.Git: объединить одну папку внутри репо

Я хочу перенести свой пакет Python, python_toolbox на Python 3. Но мне не нравится идея использования 2to3, а также поддержка как Python 2, так и Python 3 с использованием того же кода. (Потому что для меня важно, чтобы мой код был красивым, и я не нахожу код, написанный как для Python 2, так и для Python 3, чтобы быть красивым.)

Я хочу иметь две отдельные папки исходного кода, одну для Python 2.x и один для Python 3.x. Это позволит мне написать каждую версию кода, адаптированную к соответствующей основной версии Python. Я хочу, чтобы обе папки находились в одном и том же репо, и setup.py будет выбирать между ними динамически в зависимости от версии Python, запускающей его. Все идет нормально.

Теперь вот где мне нужна помощь: я хочу иметь возможность делать слияния из исходной папки Python 2.x в исходную папку Python 3.x. Зачем? Когда я разрабатываю функцию в папке Python 2.x, я хочу иметь эту функцию и в версии Python 3.x. Я не хочу копировать их вручную. Я хочу объединить их в папку Python 3.x, и я полностью ожидаю прекрасного слияния, когда мне придется использовать мое решение, чтобы решить, как объединить функции, которые были реализованы для Python 2.x, в код, который был изменен для Python 3.x.

Вопрос в следующем: Как я могу это сделать? Эти папки являются папками внутри репозитория Git, они не являются самими репозиториями Git. Я думал об использовании подмодулей Git, которые я никогда раньше не использовал, но чтение о них в Интернете приводит к страшной картине. (Термин «sobmodules» был выброшен.)

Любые другие идеи, как я мог бы объединиться между этими папками в моем Git repo?

+0

Давным-давно кто-то писал: «Комплекс лучше, чем сложный». и «практичность превосходит чистоту». Я бы использовал то, что, как известно, работает – JBernardo

ответ

1

Я рекомендую использовать ветви. Посвятите свои ветви любой версии. Вы можете использовать git branch --orphan, чтобы создать полностью независимую ветвь. (Это может усложнить слияние, поскольку git не сможет найти общего предка.)

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

+0

, я согласен, за исключением того, что в этом случае я бы не рекомендовал использовать '--orphan'. – mnagel

+0

Я добавил '--orphan', чтобы проиллюстрировать, что он есть и готов к использованию. Я также включил описание риска этого. – Oznerol256

0

Вы можете создать ветви, имея две версии в отдельных хранилищах, а другую - в качестве пульта. Параметр toplevel с setup.py и любая метаинформация PyPi, readme и т. Д. Также будут репозиторием. Макет каталога будет выглядеть следующим образом:

/root/ 
    .git/ 
    setup.py 
    read.me 
    python2/ 
     .git/ 
     source.py 
    python3/ 
     .git/ 
     source.py 

Два суб Хранилища могут быть связаны с тем, что вы можете объединить между ними, например,

cd /root/python2 
git remote add python3 ../python3 
cd /root/python3 
git remote add python2 ../python2 

Затем вы можете сделать обычный git fetch, cherry-pick или даже merge между ними.

В основном репо и для выпуска вещей вы используете git submodules feature, чтобы скоординировать, какую версию отдельных субрепозиториев вы хотите получить, чтобы иметь последовательное представление о проекте.

В подмодулях git есть много вещей в Интернете. Я бы начал с this question on nested repos и проработал через ссылки и документы.

Here's an explanation3 поддеревья объединяет и сравнивает его с работой с подмодулями. В принципе, слияния поддерева объединили бы идею наличия обычных ветвей для Py2 и Py3 (как в the answer by Oznerol256) в одном репо с идеей иметь иерархически организованное репо.

Смежные вопросы