Можно ли отправить git stash в удаленный репозиторий? - PullRequest
178 голосов
/ 11 октября 2009

Можно ли в git создать тайник, перенести тайник в удаленный репозиторий, получить тайник на другом компьютере и применить тайник?

Или мои варианты:

  • Создать патч и скопировать патч на другой компьютер, или
  • Создать второстепенную ветвь и передать в нее незавершенную работу?

Ответы [ 9 ]

70 голосов
/ 09 марта 2011

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

Таким образом, я надеюсь, что вы сможете увидеть, как я это делал, вместо того, чтобы просто слепо копировать / вставлять вещи.


Вот шаг за шагом.

Предположим, что источник в ~ / OLDREPO содержит тайники. Создайте тестовый клон, не содержащий тайников:

cd ~/OLDREPO
git clone . /tmp/TEST

Вставить все тайники как временные ветви:

git send-pack /tmp/TEST $(for sha in $(git rev-list -g stash); \
    do echo $sha:refs/heads/stash_$sha; done)

Цикл на приемном конце для преобразования обратно в тайники:

cd /tmp/TEST/
for a in $(git rev-list --no-walk --glob='refs/heads/stash_*'); 
do 
    git checkout $a && 
    git reset HEAD^ && 
    git stash save "$(git log --format='%s' -1 HEAD@{1})"
done

Очистите ваши временные ветки, если хотите

git branch -D $(git branch|cut -c3-|grep ^stash_)

Сделайте список git stash, и вы получите что-то вроде этого:

stash@{0}: On (no branch): On testing: openmp import
stash@{1}: On (no branch): On testing: zfsrc
stash@{2}: On (no branch): WIP on sehe: 7006283 fixed wrong path to binary in debianized init script (reported as part of issue
stash@{3}: On (no branch): WIP on debian-collab: c5c8037 zfs_pool_alert should be installed by default
stash@{4}: On (no branch): WIP on xattrs: 3972694 removed braindead leftover -O0 flag
stash@{5}: On (no branch): WIP on testing: 3972694 removed braindead leftover -O0 flag
stash@{6}: On (no branch): WIP on testing: db9f77e fuse_unmount_all could be starved for the mtx lock
stash@{7}: On (no branch): WIP on xattrs: db9f77e fuse_unmount_all could be starved for the mtx lock
stash@{8}: On (no branch): WIP on testing: 28716d4 fixed implicit declaration of stat64
stash@{9}: On (no branch): WIP on emmanuel: bee6660 avoid unrelated changes

На исходном репозитории тоже самое выглядело как

stash@{0}: WIP on emmanuel: bee6660 avoid unrelated changes
stash@{1}: WIP on testing: 28716d4 fixed implicit declaration of stat64
stash@{2}: WIP on xattrs: db9f77e fuse_unmount_all could be starved for the mtx lock
stash@{3}: WIP on testing: db9f77e fuse_unmount_all could be starved for the mtx lock
stash@{4}: WIP on testing: 3972694 removed braindead leftover -O0 flag
stash@{5}: WIP on xattrs: 3972694 removed braindead leftover -O0 flag
stash@{6}: WIP on debian-collab: c5c8037 zfs_pool_alert should be installed by default
stash@{7}: WIP on sehe: 7006283 fixed wrong path to binary in debianized init script (reported as part of issue #57)
stash@{8}: On testing: zfsrc
stash@{9}: On testing: openmp import
59 голосов
/ 11 октября 2009

Невозможно получить его с помощью fetch или около того, refspec для зеркала - fetch = +refs/*:refs/*, и даже если тайник * refs/stash, он не отправляется Явный refs/stash:refs/stash также не имеет никакого эффекта!

Это все равно будет сбивать с толку, так как это не приведет к загрузке всех тайников, только самых последних; список тайников - это reflog из ссылки refs/stashes.

30 голосов
/ 29 марта 2010

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

Я работаю над функцией в собственной ветке. Ветвь не объединяется с мастером и не выдвигается до тех пор, пока она не будет завершена, или пока я не сделаю коммиты, которые мне удобно показывать публике. Так что я делаю, когда хочу перенести не поэтапные изменения на другой компьютер:

  • Сделать коммит с сообщением коммита например "[non-commit] FOR TRANSFER ONLY", с содержанием, которое вы хотите передать.
  • Войдите на другой компьютер.
  • Затем выполните:

    git pull ssh+git://<username>@<domain>/path/to/project/ rb:lb

    URL может отличаться для вас, если вы обращаетесь к своему хранилищу другим способом. Это вытянет изменения из этого URL из удаленной ветви "rb" в локальную ветку "lb" Обратите внимание, что на моем компьютере запущен ssh-сервер, и я могу получить доступ к хранилищу таким образом.

  • git reset HEAD^ (подразумевается --mixed)

    Сбрасывает HEAD, чтобы он указывал на состояние перед фиксацией "[non-commit]".

Из git-reset (1): «--mixed: Сбрасывает индекс, но не рабочее дерево (т.е. измененные файлы сохраняются, но не помечаются для фиксации) [...]"

Таким образом, в конце у вас будут ваши изменения в файлах, но не будет сделано никаких фиксаций для мастера и нет необходимости в тайнике.

Это, однако, потребует от вас git reset --hard HEAD^ в репозитории, в котором вы сделали «[non-commit]», так как этот коммит является мусором.

18 голосов
/ 28 августа 2013

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

Для меня работает фиксация моего текущего кода (в ветке, над которой я работаю в одиночку). Когда я доберусь до моего другого компьютера, сделайте извлечение, затем отмените коммит с помощью:

git reset --soft HEAD^

Продолжайте работать, как вы, со всеми текущими изменениями, незафиксированными и неподготовленными.

Надеюсь, это поможет.

13 голосов
/ 07 ноября 2016

Кажется, есть очень хитрый способ решить эту проблему. Вы можете использовать git diff > file.diff (и зафиксировать файл), а затем восстановить изменения, используя git apply file.diff (из любого места) для достижения того же результата.

Это было объяснено здесь .

9 голосов
/ 11 октября 2009

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

3 голосов
/ 22 сентября 2011

AFAIK вся идея тайника в том, чтобы спрятать что-то не столь важное под локальным ковром. Никто не должен знать о вашем любимом дерьме ;-) Единственное «но» - это: а если я буду работать на паре рабочих станций? Тогда scp намного лучше.

0 голосов
/ 24 апреля 2017

Просто используйте Dropbox, как этот парень. Таким образом, вам не нужно беспокоиться о загрузке тайников, поскольку весь ваш код будет сохранен.

http://blog.sapegin.me/all/github-vs-dropbox

0 голосов
/ 28 июля 2014

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

commit_and_push_ ( ) {
    # This will:
    #  1. checkout a new branch stash-XXX
    #  2. commit the current changes in that branch
    #  3. push the branch to the remote
    local locbr=${1:-autostash-XXX}
    git checkout -b $locbr
    git add .
    git commit -a -m "Automatically created commit"
    git push origin $locbr
    echo "Autocommitted changes in branch $locbr ..."
}

Используйте как:

commit_and_push_ my-temp-branch
commit_and_push_
...