2010-07-28 6 views
0

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

Я ищу, чтобы быстро вытащить любые изменения из источника/мастера вместе с любыми модифицированными файлами.

+0

Ваш вопрос очень неясен. Что именно ты пытаешься сделать? Может быть, объясните, почему «git pull origin master» не работает для вас. – Daenyth

+0

git pull origin master тянет все совершенные изменения, а не изменения, которые еще не были выполнены. –

ответ

2

сначала вытащите заработанные изменения, затем потяните разность незафиксированных изменений.

git pull 
ssh [email protected] bash -c "cd && cd svn && git diff HEAD /home/aulfeldt/svn" | patch -p1 
+0

Чтобы включить поэтапные файлы, сравните с HEAD вместо индекса. – Cascabel

+0

спасибо :), что действительно делает мой день! –

+0

Обратите внимание, что в дополнение к ограничениям, о которых я упоминал в комментарии к моему ответу, для этого требуется доступ оболочки к рассматриваемому репо. Это полностью противоположно тому, как обычно устанавливаются общие хранилища - голые и доступ только через git-shell. – Cascabel

3

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

Редактировать: Этот ответ о вытягивании с git. Если вы хотите скопировать файлы (или скопировать diff), как в ответе OP, вы можете это сделать, но в нижней строке указано, что это операция, требующая доступа к файловой системе, а не удаленная операция git.

+0

его более эффективно вытащить совершенные изменения с помощью git, а затем вытащить разности после этого. не нужно совершать изменения, прежде чем потянуть его (см. мой ответ) –

+0

@ Артур Ульфельдт: Это действительно зависит от того, что вы подразумеваете под «более эффективным». Это означает, что у вас должно быть публичное доступное не-обнаженное репо и быть в непосредственной связи с его владельцем, чтобы знать, когда он находится в правильном состоянии для вашего измененного тяги, вместо того, чтобы позволить им отмечать определенное состояние как готовое к (нестабильно, тестировать) тянуть, совершая его. У обещаний есть цель, я обещаю, и их довольно легко сдуть, если они окажутся не такими, какими вы хотели. – Cascabel

+1

Oof, downvote? Мой ответ, строго говоря, правильный, даже если можно обойти git и потянуть таким образом. – Cascabel

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