2014-01-06 3 views
1

Я тестирую новую функцию git submodule add -b (после git 1.8.2), которая создает подмодуль, который якобы отслеживает ветку, а не фиксацию. Я использую git version 1.8.4.msysgit.0. Функция отслеживания ветвей для подмодулей, кажется, отлично работает в оригинальном суперпроекте, но не работает, как только суперпроект клонируется. Чтобы быть более конкретным:Как сохранить статус субмодуля git после ветвления после клонирования суперпроекта?

То, что я сделал это типично, и примерно так,

1. create a git repo (called common): ... 
2. create a main project (called main), which uses common as a library/submodule. 
mkdir main && cd main 
git init 
git submodule add -b master url_to_common.git 
git commit -m "initial commit" 
cd common 
git status 

Как рекламируются, добавленный подмодуль отслеживает главный филиал подмодуль репо. И я получил:

# On branch master 
nothing to commit, working directory clean 

Кроме того, если я git pull или git push, я получаю

Already up-to-date. 
Everything up-to-date 

соответственно.

Однако, если я клонирую проект main каким-либо образом, подмодуль common в клонированном проекте теряет статус «Вкл.». И я не мог git pull или git push внутри папки common, как в прототипе проекта main. Конечно, я могу добавить origin master, чтобы сделать pull и push работу для common в клонированном проекте, но это, похоже, превзошло цель иметь подмодуль отслеживания (subodule add -b).

Команды я использовал для клонирования и проверить Подмодули были:

cd main 
git clone . ../main2 --recursive 
cd ../main2/common 
git status 

я получил:

# HEAD detached at 0259d75 
nothing to commit, working directory clean 

Я также попытался git clone . ../main3 --recurse-submodules, а также,

git clone . ../main4.git --bare 
git clone url_to_main4.git --recursive 

то же самое вещь бывает main3 и main4.

В целом, я создал суперпроект с подмодулем, отслеживающим его главную ветвь. Функция отслеживания ветвей теряется, как только я пытался клонировать ее и работать над ней в другом месте. Мне кажется, что единственный способ сохранить подмодули отслеживания ветвей - сжать исходный проект main и скопировать его. Я что-то пропустил в этом случае или копировал исходный проект по лучшему, что у меня есть?

Мой вопрос в том, как сохранить возможность отслеживания ветвей после клонирования суперпроекта. Я особенно заинтересован в том, чтобы сделать работу main4.git, потому что она включает в себя пустой клон на удаленном сервере.

Примечание: указание ветки после пропадания ветки (например, Git submodules: Specify a branch/tag) не то, что я ищу, потому что информация, указанная в git submodule add -b, по-прежнему утеряна, и мы вернемся к квадрату. Мы могли бы также удалить субмодуль и добавить его снова.

ответ

0

Подмодули Git отслеживаются с помощью специальных ссылок фиксации. Не через ветки. Следовательно, даже если вы находитесь в HEAD от master, ваш проект main будет отслеживать конкретную фиксацию с common.Вот почему подмодули очень статичны в ссылке, и это иногда вызывает путаницу и проблемы :)

This blog описывает эту концепцию довольно хорошо.

0

Существуют различные варианты использования git. Но для моего случая следующие работали для git 1.8.5.2 (и, вероятно, позже). В принципе, сначала rm подмодуль полностью, а затем добавьте его обратно. Естественно, что подмодули являются современными и непрерывными.

Обратите внимание, третья линия rm ... необходимо потому, что мерзавец (по 1.8.5.2) оставит .git/modules/common в суперпроекте, что предотвращает подмодуль от добавления обратно.

1

Для тех, кто еще с этой проблемой:

Как ответы изложили, ваш подмодуль отслеживает фиксации. На самом деле это не проблема, подмодуль представляет собой внешнюю зависимость в один момент времени (т. Е. Фиксацию), а не активный поток развития (ветвь). Вы вручную обновляете эту зависимость по своему усмотрению (и, теоретически, только в филиале мастера)

Вы действительно заботитесь о своей ветке только при совершении коммитов. Фиксирование, не находясь на ветке, делает оторванную голову, и ваша команда перестает работать.

Я решил это в нашей студии, добавив предварительно совершить крюк для отклонения фиксаций, если не на ветке:

#!/bin/sh 

function parse_git_branch_check { 
    if [[ ${branch_name} == "* (detached from "* ]]; then 
     echo "********************************************" 
     echo "You need to be on a branch before committing" 
     echo "********************************************" 
     exit 1 
    else 
     echo "-- You are on branch $branch_name --" 
     exit 0 
    fi 
} 
function parse_git_branch { 
    git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' 
} 

branch_name=$(parse_git_branch) 
parse_git_branch_check; 

Этот крюк стремится к супер репо, наряду с этим BAT (да, знает, извините) скрипт для установки крюков

REM - Create links for all submodules to our pre-commit hooks for preventing submissions without a branch 

if EXIST .git\hooks\pre-commit (
    del .git\hooks\pre-commit 
) 
mklink /h .git\hooks\pre-commit pre-commit 

FOR /F "tokens=*" %%i IN ('DIR .git\modules /A:D /b') do (
    if EXIST .git\modules\%%i\hooks\pre-commit (
     del .git\modules\%%i\hooks\pre-commit 
    ) 
    mklink /h .git\modules\%%i\hooks\pre-commit pre-commit 
) 

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

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