Как подружить Git с сетевой папкой?

Question

[KrD]

Nota bene: публикую вопрос своего друга Ve1xeor

Особенности работы вынуждают пользоваться Git`ом в несколько нетрадиционном ключе:
репозиторий у меня хранится на локальном диске, тогда как рабочая копия находится на удалённом сервере, доступ к которому имеется через подключенный сетевой диск. У меня на машине стоит Windows 7 x86 и Git 1.8.4 (git-1.8.4-preview20130916.exe), сервер предположительно на Linux, права для работы в сетевой папке есть в полном объёме (rwx).

Ниже опишу, как я создаю репозиторий:
в Проводнике перехожу в каталог \\server\workingfolder, в каталоге вызываю консоль (Rclick -> Git Bash)

$ git init --separate-git-dir=/C/my_repo.git

В папке C:\my_repo.git создаётся пустой репозиторий, в папке \\server\workingfolder неприметный файл .git;
и тут возникает проблема:

$ git add .
fatal: Unable to create `//server/workingfolder/../../../C:/my_repo.git/index.lock` No such file or directory

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

Answer 1

[mayorovp]

Попробуйте git из cygwin — так как cygwin эмулирует корневую файловую систему, эта проблема может исчезнуть.

Comments

[KrD]

Да, я ещё вчера автору вопроса то же самое сказал; к тому же, если сетевая папка примонтирована как диск, то под cygwin всё становится просто и прозрачно. Он обещал сегодня проверить.

[KrD]

Ve1xeor:
Спасибо всем огромное за помощь!
Cygwin оказался лекарством, но не панацеей. Он решил мои проблемы с адресацией, но всё так же «out of the box» Git не дружит с русским языком (освещалось тут), поэтому я, не мудрствуя лукаво, использовал уже давно известное решение:

$ git config --global core.quotepath off
$ git config --global --unset i18n.commitencoding
$ git config --global --unset i18n.logoutputencoding

Касаемо создания репозитория, выглядело это примерно так:

$ cd /cygdrive/u/workingfolder
$ git init --separate-git-dir=/cygdrive/c/my_repo.git

после чего проблем с добавлением в stage/commit не возникло.

Из всей этой истории для себя вынес, что msysgit, нравится нам это или нет, сыроват и не готов работать “прямо из коробки”, но возможно он просто сделан в Linux style – допили себе всё сам.

PS: в целом, впечатление от Git позитивное — всё прозрачно, понятно и гибко.
Можете кидать в меня помидорами, но работа с консолью оказалась для меня проще графического клиента просто из-за прозрачности операций – когда пишешь команду, понимаешь что делаешь, да и функциональность в полной мере GUI интерфейс не представляет. Правда, проблема с кодировками обязывает внимательно следить за тем, что и в какой кодировке сохраняешь: даже умудряется ссориться с UTF-8 – выводит BOM, с UTF-8 without BOM соответственно таких проблем нет ввиду отсутствия FEFF в начале файла.

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

PPPS: спасибо всем участвовавшим в обсуждении проблемы — вы утвердили меня в мысли пойти поговорить с руководством о внедрении позитивных ИТ подходов разработки приложений.

---

Выскажу своё личное мнение: использование консольных утилит вместо графических — отнюдь не вынужденное зло, а закономерное благо. Я рад за Дмитрия.

Answer 2

[Николай Васильчук]

Подключите сетевой диск и работайте как обычно.

Comments

[KrD]

Голосом Ve1xeor-a:

Спасибо за совет, но, к сожалению, не помогло:

$ git config --get core.worktree
//server/workingfolder

Подключаю сетевой диск с буквой U:

$ git config core.worktree /u/workingfolder
$ git config --get core.worktree
u:/workingfolder
$ git add .
fatal: Unable to create `u:/workingfolder/../../c:/my_repo.git/index.lock` No such file or directory

Полагаю, это какие-то особенности клиента Git под Windows.

[Николай Васильчук]

Попробуйте использовать SourceTree

Answer 3

[Максим Дьяченко]

Полагаю что у тебя (или точнее как я понимаю у Димы?) гит пытается писать в изначальный репозиторий исходя из текущего положения.
Т.е. мы находимся непонятно где, а репозиторий у нас на Це. Пытаемся построить к нему путь, но поскольку родная среда это линукс то у нас это не выходит.

Давай определимся с задачей.
Если я правильно понял, то задача в синхронизации репозитория разработчика с продакшеном на сетевом диске?
Если так, то нужно делать ДВА репозитория и синхронизировать их через пулл/пуш.

Если я неверно понял задачу, то можно подробнее?

Comments

[KrD]

Ve1xeor:
Я пишу приложения Oracle Forms / Oracle Reports, и в 100% случаев приложения пишутся для нашей компании (достаточно крупной). Специфика разработки заключается в необходимости подключать уже имеющиеся системы и компилировать написанное ПО под линукс на этапах тестирования и отладки. Это возможно только на нашем Linux сервере, который является и хранилищем и на нём же крутится компилятор. Из-за этого файлы разрабатываемых приложений изначально создаются там, где они будут лежать после релиза. Я могу создать проект в другом месте, но чтобы проверить его работоспособность мне придётся копировать его на сервер, что крайне неудобно.

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

Делать 2 репозитория — 1 на локальной машине и 1 на сервере – неудобно из-за специфики отладки, тут же вылезет ненужная куча коммитов и пушей при синхронизации 2х репозиториев.

[Максим Дьяченко]

Какая куча? Не понимаю проблему.

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

Если и это не поможет, то тогда давайте подробнее проблему :)

[Алексей Сторожев]

плюсую за хук с батником

вообще мне показалось, что тут всё намекает на необходимость внедрения CI

[KrD]

Ve1xeor:
Ох, видимо я был неправильно понят. Давайте по пунктам.
1. Сервер не мой. Не мой в том плане, что не я ему хозяин (sudo/root/et cetera). Он корпоративный и за него отвечают вполне конкретные люди, которые никакой софт туда доставлять не станут. Опять же плодить там лишние файлы (репозиторий Git`а) мне не дадут. Намеренно за этим следить не будут, но при случае удалят.

2. Компиляция происходит только на сервере, для запуска ПО необходимо опять же залить исходный код на сервер. Т.е. грубо говоря на локальной машине код не скомпилируешь, не запустишь, не отдебажишь, не посмотришь как выглядит программа вообще.

3. Если даже делать два репозитория Git`а, то каждый раз когда я сделаю изменение кода и захочу посмотреть, как оно работает мне придётся прожимать commit + push чтобы файлы пришли на сервер, при этом теряется смысл системы контроля версий, который изначально заключается для меня в том, чтобы сохранять код в вполне конкретных состояниях (стабильная версия, закончен функциональный блок, завершен модуль).

Поэтому я и устраиваю танцы с бубном вокруг separated-git-dir. Сейчас мне проблема видится в том, что в Linux и в Windows по-разному записываются адреса, а Git непонятно почему пытается по относительному пути пройти из samba-шары Linux в каталог Windows.

[Максим Дьяченко]

Дим, файлы проекта являются неотъемлемой частью репозитория.
Мне конечно сложно себе представить что кто-то будет удалять папку .git в папке исходников, но если это так, то мне кажется второй мой вариант тут оптимальный:
работаем с локальным репозиторием а для переноса на сервер используем ОТДЕЛЬНЫЙ батник который тупо копирует все файлы, или если их много то сравнивает дату/время изменения и копирует если изменился.

[KrD]

Пожалуй, tar/untar для этого как нельзя лучше подойдёт, Максим, — задержка на упаковку/распаковку с лихвой окупает I/O в сетевой составляющей.

[Максим Дьяченко]

Кстати да, об этом я как-то не подумал.