2010-03-09 3 views
417

У меня есть каталог A с каталогами, соответствующими каталогу B. В каталоге A могут быть другие необходимые файлы. Каталог B - это репозиторий git.Как клонировать в непустой каталог?

Я хочу клонировать каталог B в каталог A, но git-clone не позволит мне, так как каталог не пуст.

Я надеялся, что он просто клонирует .git, и поскольку все файлы соответствуют мне, я мог бы оттуда оттуда?

Я не могу клонировать в пустой каталог, потому что у меня есть файлы в каталоге A, которые не находятся в каталоге B, и я хочу их сохранить.

Копирование .git не является вариантом, так как я хочу, чтобы refs нажимал/тянул, и я не хочу настраивать их вручную.

Есть ли способ сделать это?

Обновление: Я думаю, что это работает, может ли кто-нибудь увидеть какие-либо проблемы? ->

cd a 
git clone --no-hardlinks --no-checkout ../b a.tmp 
mv a.tmp/.git . 
rm -rf a.tmp 
git unstage # apparently git thinks all the files are deleted if you don't do this 
+2

, возможно, вы могли бы изменить принятый ответ? –

ответ

130

В следующей команды оболочки existing-dir это каталог, содержимое которого соответствует отслеживаемые файлов в repo-to-clone мерзавца хранилище.

# Clone just the repository's .git folder (excluding files as they are already in 
# `existing-dir`) into an empty temporary directory 
git clone --no-checkout repo-to-clone existing-dir/existing-dir.tmp # might want --no-hardlinks for cloning local repo 

# Move the .git folder to the directory with the files. 
# This makes `existing-dir` a git repo. 
mv existing-dir/existing-dir.tmp/.git existing-dir/ 

# Delete the temporary directory 
rmdir existing-dir/existing-dir.tmp 
cd existing-dir 

# git thinks all files are deleted, this reverts the state of the repo to HEAD. 
# WARNING: any local changes to the files will be lost. 
git reset --hard HEAD 
+0

@ russel ах ты, спасибо –

+4

Мне нужно было выполнить 'git reset --hard HEAD' или он не отказался бы от« удаленных »файлов. – Dimitar

+14

'git reset HEAD' отлично работал для меня. 'git reset --hard HEAD' уничтожает любые изменения в ваших файлах, поэтому, если они не совсем такие же, как файлы в репозитории, вы не должны этого делать. – Tgr

3

Может быть, я неправильно понял ваш вопрос, но не было бы проще, если бы вы копировать/перемещать файлы от А до обратного РЕПО В мерзавца и добавить необходимые из них с мерзавца добавить?

UPDATE: С мерзавца документ:

Клонирование в существующий каталог разрешается только если каталог пуст.

ИСТОЧНИК: http://git-scm.com/docs/git-clone

+2

Нет, владелец и файлы могут быть произвольными. Это для ситуации с несколькими разработчиками. У всех нас есть существующие каталоги, и только один из них имеет git checkout. У всех нас есть одинаковые подмножества файлов, поэтому мы хотим, чтобы другие разработчики могли клонировать, сохраняя при этом свои файлы. И он должен быть таким же элегантным и удобным, насколько это возможно. –

+0

Честно говоря, я не вижу смысла развиваться в таком состоянии. Вы не можете использовать ветви и операции слияния? Или иметь субрепозиторы с внешними зависимостями? Почему вы хотите полагаться на один «git checkout»? –

+5

«Одиночная проверка git» не является точкой всего испытания. Просто так оно и есть, и нам нужен способ двигаться вперед. Я обновил исходный вопрос с помощью решения, которое работает. Однако я ценю отзывы. –

3

Я искал что-то подобное, и вот что я придумал:

Моя ситуация одна, где у меня есть активный веб-дерево, и я пытался создать удаленный репозиторий для него без движения любой из файлов в текущем веб-дереве. Вот что я сделал:

  1. Перейти к веб-дерева и запустить git init
  2. Перейти к предполагаемому месту нахождения хранилища и запуск: git clone --bare /path/to/web/repo
  3. Редактировать конфигурационный файл в моем удаленный репозиторий и удалить раздел [remote "origin"] ,
  4. Добавить раздел [remote "origin"] в .git/config в веб-дереве, указав на новое дистанционное репо.
+0

Мне нравится этот рецепт много. – dland

+0

«git clone --bare» здесь лишний и крутой. Почему не просто «git remote add origin ' в первую очередь? – Araxia

24

Вот что я в итоге сделал, когда у меня была такая же проблема (по крайней мере, я думаю, что это та же проблема). Я зашел в справочник А и запустил git init.

Поскольку я не хотел, чтобы файлы в каталоге A сопровождались git, я редактировал .gitignore и добавил к нему существующие файлы. После этого я побежал git remote add origin '<url>' && git pull origin master et voíla, B «клонировал» в A без единого икоты.

+0

работал идеально для меня, thx :) – nerdess

+6

Чтобы быть ясным, команда «git remote add origin (url) && git pull origin master» – Pre101

+0

Лучший ответ мне! –

539

Это работает для меня:

git init 
git remote add origin PATH/TO/REPO 
git fetch 
git reset origin/master # this is required if files in the non-empty directory are in the repo 
git checkout -t origin/master 

ПРИМЕЧАНИЕ:-t установит вверх по течению ветвь для вас, если это то, что вы хотите, и это обычно.

+19

Это имеет смысл. –

+2

Я использую этот метод, он отлично работает! Одна нота, опция -t должна быть --track, которая не находится в обзоре, но находится в деталях; git help checkout. http://git-scm.com/docs/git-checkout – AnneTheAgile

+64

Это не работает в непустой директории, когда входящие файлы уже существуют (как описывает исходный вопрос). Но если вы «git reset origin/master» после «git fetch», он будет работать (также сохраняя любые локальные изменения). – Araxia

6

Еще один простой рецепт, кажется, работает хорошо для меня:

git clone --bare $URL .git 
git config core.bare false 

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

+1

Голые репозитории настроены немного по-другому, и хотя это работает, я бы не рекомендовал его. :) – ThorSummoner

+1

Можете ли вы уточнить? Какая разница? –

+0

Только два отличия: 1.) Файл '.git/config' указывает, что репозитории являются голыми. 2.) Файлы, обычно хранящиеся в '.git', хранятся в корне (который вы назвали' .git') – mozey

74

Небольшое изменение в одном из ответов, которые работали для меня:

git init 
git remote add origin PATH/TO/REPO 
git pull origin master 

, чтобы начать работать на главной ветви сразу.

+7

Вы также можете использовать 'origin' вместо' PATH/TO/REPO' в последней строке. –

+0

должен был выполнить сброс HEAD - для очистки грязного существующего каталога, не удаляя ненужные файлы, указанные в gitignore. –

+0

Это тот, который действительно работал для меня, в отличие от ответа @ cmcginty. – certainlyakey

0

мне понравился ответ Дейл, и я также добавил

git clone --depth 2 --no-checkout repo-to-clone existing-dir/existing-dir.tmp 
git branch dev_new214 
git checkout dev_new214 
git add . 
git commit 
git checkout dev 
git merge dev_new214 

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

8

Это работает для меня:

cd existing_folder 
git init 
git remote add origin path_to_your_repo.git 
git add . 
git commit 
git push -u origin master 
3

это работа для меня, но вы должны объединить файлы удаленного хранилища для локальных файлов:

git init 
git remote add origin url-to-git 
git branch --set-upstream-to=origin/master master 
git fetch 
git status 
+0

Спасибо, помощник. Эти команды отлично работали ... Спасибо –

8
git init 

git remote add origin PATH/TO/REPO 

git fetch 

git checkout -t origin/master -f 

Измененный @ cmcginty отвечают - без -f это не сработало для меня

0

Я использовал это несколько минут назад, требуя наименее потенциально разрушить ive:

cd existing-dir 
git clone --bare repo-to-clone .git 
git config --unset core.bare 
git reset 

И voilá!

0

Вот что я делаю:

git clone repo /tmp/folder 
cp -rf /tmp/folder/.git /dest/folder/ 
cd /dest/folder 
git checkout -f master 
Смежные вопросы