GIT клон репо через локальную файловую систему в Windows

Question

Я полный нуб, когда дело доходит до GIT. Я просто делал свои первые шаги за последние несколько дней. Я установил репо на своем ноутбуке, снял Trunk из проекта SVN (у меня были некоторые проблемы с ветками, но они не работали), но там все вроде нормально.

Теперь я хочу иметь возможность вытащить или перенести с ноутбука на мой основной рабочий стол. Причина в том, что ноутбук удобен в поезде, так как я провожу 2 часа в день в пути и могу сделать хорошую работу. Но моя главная машина дома отлично подходит для развития. Поэтому я хочу, чтобы я мог вернуться с ноутбука на главный компьютер, когда вернусь домой. Я подумал, что самый простой способ сделать это - просто поделиться папкой с кодом в локальной сети и выполнить:

git clone file://192.168.10.51/code

к сожалению, это не работает для меня:

поэтому я открываю git bash cmd и набираю указанную выше команду. Я нахожусь в C: \ code (общая папка для обеих машин), вот что я получаю:

Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

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

Будут другие места, которые будут официальными точками хранения и местами, из которых будут извлекаться другие разработчики, CI-сервер и т. Д., Только для того, чтобы я мог работать в одном репо на двух машинах.

По предложению Себастьяна я получаю следующее:

C:\code>git clone --no-hardlinks file://192.168.10.51/code
Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

** РЕДАКТИРОВАТЬ - ОТВЕТ **

Спасибо всем, кто помог. Я попробовал сопоставить диск, и это сработало, поэтому я подумал, что вернусь и попробую без сопоставления. Окончательный результат был:

git clone file://\\\\192.168.0.51\code

Это отлично сработало.

Спасибо

Answer 1

Вы можете указать URL-адрес пульта, применив путь UNC к протоколу файлов. Для этого необходимо использовать четыре слеша:

git clone file:////<host>/<share>/<path>

Например, если ваш основной компьютер имеет IP 192.168.10.51 и имя компьютера main, и у него есть общий ресурс с именем code, который сам является репозиторием git, то оба Следующие команды должны работать одинаково:

git clone file:////main/code
git clone file:////192.168.10.51/code

Если репозиторий Git находится в подкаталоге, просто добавьте путь:

git clone file:////main/code/project-repository
git clone file:////192.168.10.51/code/project-repository

Answer 2

$ git clone --no-hardlinks /path/to/repo

Приведенная выше команда использует обозначение пути POSIX для каталога с вашим репозиторием git. Для Windows это (каталог C:/path/to/repo содержит .git каталог):

C:\some\dir\> git clone --local file:///C:/path/to/repo my_project

Хранилище будет клонировано в C:\some\dir\my_project. Если вы пропустите file:/// part, то подразумевается опция --local.

Answer 3

ответ с именем хоста у меня не сработал но это сделал:

файл git clone: ​​////home/git/repositories/MyProject.git/

Answer 4

Мне удалось это сделать с помощью file: //, но с одним дополнительным слешем для обозначения абсолютного пути.

git clone file:///cygdrive/c/path/to/repository/

В моем случае я использую Git на Cygwin для Windows, который выможно увидеть из-за части / cygdrive / c в моих путях.С некоторыми изменениями пути он должен работать с любой установкой git.

Добавление удаленного работает аналогично

git remote add remotename file:///cygdrive/c/path/to/repository/

Answer 5

Может быть сопоставить общий ресурс как сетевой диск, а затем сделать

git clone Z:\

В основном просто предположение; Я всегда делаю это с помощью ssh. Конечно, следование этому предложению будет означать, что вам нужно будет подключать этот диск каждый раз, когда вы нажимаете / извлекаете данные из ноутбука. Я не уверен, как вы настраиваете ssh для работы под Windows, но если вы собираетесь делать это много, возможно, стоит изучить.

Answer 6

Не уверен, было ли это из-за моей версии git (1.7.2) или чего-то еще, но перечисленные выше подходы с использованием имени компьютера и параметров IP не работали для меня. Дополнительная деталь, которая может / не может быть важной, состоит в том, что репо было голым репо, которое я инициализировал и перенес с другой машины.

Я пытался клонировать project1, как указано выше, с помощью команд вроде:

$ git clone file:////<IP_ADDRESS>/home/user/git/project1
Cloning into project1...
fatal: '//<IP_ADDRESS>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

и

$ git clone file:////<MACHINE_NAME>/home/user/git/project1
Cloning into project1...
fatal: '//<MACHINE_NAME>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

Что сделало работа для меня было чем-то проще:

$ git clone ../git/project1
Cloning into project1...
done.

Примечание. Несмотря на то, что репо, клонируемое из, было пустым, это привело к «нормальному» клону со всеми фактическими файлами кода / изображений / ресурсов, на которые я надеялся (в отличие от внутренних элементов git-репо).

Answer 7

Введите абсолютные или относительные пути.

Например, первый из приведенных ниже использует абсолютные пути:

(это изнутри папки, содержащей хранилище и резервную копию в качестве подпапок. Также помните, что папка резервной копии не изменяется, если она уже содержит что-либо. И если ее нет, новая папка создано)

~/git$ git clone --no-hardlinks ~/git/git_test1/   ~/git/bkp_repos/

Следующие используют относительные пути:

~/git$ git clone --no-hardlinks git_test1/   bkp_repos2/

Answer 8

Обратите внимание, что с 2016 года и MingW-64 git.exe в комплекте с Git для Windows поддерживается UNC-путь.
(См. " Как msys, msys2 и MinGW-64 связаны друг с другом? ")

А в Git 2.21 (февраль 2019 г.) эта поддержка распространяется даже в оболочке msys2 (с кавычками вокруг пути UNC).

См. коммит 9e9da23 , коммит 5440df4 (17 января 2019) Йоханнес Шинделин (dscho) .
Помощник: Ким Гайбелс (Jeff-G) .
^{(Объединено с Junio ​​C Hamano - gitster - в коммит f5dd919 , 05 февраля 2019 г.)}

До Git 2.21, из-за причуды в методе Git для появления git-upload-pack, существует проблема при прохождении путей с обратными слешами в них: Git заставит командной строки через оболочку, которая имеет различную семантику цитирования в Git для Windows (будучи программой MSYS2), чем обычные исполняемые файлы Win32 такие как git.exe сама.

Симптом состоит в том, что первый из двух обратных слэшей в путях UNC форма \\myserver\folder\repository.git is обнажена .

Теперь это смягчено:

mingw: аргументы специального случая для sh

Среда выполнения MSYS2 делает все возможное, чтобы эмулировать подстановочные знаки командной строки и удаление из кавычек, которые будут выполняться вызывающей оболочкой Unix в системах Unix.

Эти правила цитирования оболочки Unix отличаются от правил цитирования, применяемых к cmd и Powershell в Windows, поэтому немного неудобно правильно указывать параметры командной строки при порождении других процессов.

В частности, git.exe передает аргументы подпроцессам, которые не предназначены для интерпретации как подстановочные знаки, и если они содержат обратную косую черту, они не должны интерпретироваться как escape-символы, например, при прохождении путей Windows.

Примечание: это проблема только при вызове исполняемых файлов MSYS2, а не при вызове исполняемых файлов MINGW, таких как git.exe. Однако мы часто вызываем исполняемые файлы MSYS2, особенно при установке флага use_shell в структуре child_process.

Не существует элегантного способа определить, является ли исполняемый файл .exe программой MSYS2 или MINGW.
Но так как прецедент передачи командной строки через оболочку настолько распространен, нам нужно обойти эту проблему по крайней мере при выполнении sh.exe.

Давайте введем уродливый, жестко закодированный тест, является ли argv[0] "sh", и относится ли это к MSYS2 Bash, чтобы определить, нужно ли нам цитируйте аргументы иначе, чем обычно.

Это все еще не решает проблему полностью, но по крайней мере это что-то.

Кстати, это также устраняет проблему, когда git clone \\server\repo не удался из-за неправильной обработки обратных косых черт при передаче пути к процессу git-upload-pack.

Кроме того, мы должны позаботиться о том, чтобы указывать не только пробел и обратную косую черту, но и фигурные скобки.
Поскольку псевдонимы часто проходят через MSYS2 Bash, и поскольку псевдонимы часто получают параметры, такие как HEAD@{yesterday}, это действительно важно.

См. t/t5580-clone-push-unc.sh