¿Es posible enviar un stash de git a un repositorio remoto?

Nota: Acabo de reescribir esta respuesta con 24 horas más de git-fu en mi haber :) En mi historia, todo el asunto es ahora de tres líneas. Sin embargo, no los he condensed para su conveniencia.

De esta manera, espero que puedas ver cómo hice las cosas, en lugar de tener que copiar/pegar cosas ciegamente.

Aquí está paso a paso.

Asume que es fuente en ~/OLDREPO conteniendo escondites. Crear un clon de PRUEBA que contenga no escondites:

cd ~/OLDREPO
git clone . /tmp/TEST

Empuje todos los alijos como ramas temporales:

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

Bucle en el extremo receptor para transformar de nuevo en alijos:

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

Limpie sus ramas temporales si lo desea

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

Haga una lista de git stash y hará algo como esto:

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

En el repositorio original, lo mismo parecía

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

Llego un poco tarde a la fiesta, pero creo que encontré algo que funciona para mí con respecto a esto y podría ser para usted también si sus circunstancias son las mismas o similares.

Estoy trabajando en una característica en su propia rama. La rama no se fusiona en master y se empuja hasta que esté terminada o he hecho commits que me siento cómodo mostrando al público. Entonces, lo que hago cuando quiero transferir cambios no escalonados a otro equipo es:

• Hacer un commit, con un commit mensaje como " [non-commit] FOR TRANSFER ONLY", con el contenido que quieres transferir.
• Inicie sesión en el otro equipo.

• Entonces haz:

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

  La URL puede diferir para usted si accede a su repositorio de una manera diferente. Esto extraerá los cambios de esa URL de la rama remota " rb "a la rama local"lb". Tenga en cuenta que tengo un servidor ssh que se ejecuta en mi propio equipo, y soy capaz de acceder al repositorio de esa manera.

• git reset HEAD^ (implica --mixed)

  Esto restablece la CABEZA para que apunte al estado antes de la confirmación "[non-commit]".

Desde git-reset(1): "--mixed: Restablece el índice pero no el árbol de trabajo (es decir, los archivos cambiados se conservan pero no se marcan para la confirmación) [...]"

Por lo que tendrá sus cambios en los archivos al final, pero no se realizan confirmaciones a master y no hay necesidad de un alijo.

Esto sin embargo requerirá que git reset --hard HEAD^ en el repositorio en el que hizo el "[non-commit]", ya que ese compromiso es basura.

Es un poco tarde, pero esta respuesta podría ayudar a alguien. Quería saber esto porque quería ser capaz de empujar una característica en progreso/bug/lo que sea y trabajar desde el mismo punto en otra computadora.

Lo que funciona para mí es confirmar mi código en curso (en una rama en la que estoy trabajando solo). Cuando llegue a mi otra computadora, haga un pull, luego deshaga la confirmación con:

git reset --soft HEAD^

Continúe trabajando como estaba, con todos sus cambios en curso allí, sin compromiso, y sin escenario.

Espero que ayude.

Me gustaría ir con el segundo enfoque, aunque no tengo idea de por qué no se puede comprometer a la rama master/featured . También es posible hacer la recolección de cerezas.

Parece que hay un truco muy limpio para resolver esto. puede usar git diff > file.diff (y confirmar el archivo) , luego restaurar los cambios usando git apply file.diff (desde cualquier lugar) para lograr el mismo resultado.

Esto fue explicado aquí así.

AFAIK toda la idea de stash es esconder algo no tan importante debajo de la alfombra local. Nadie debe saber acerca de su mierda favorita; -) El único "pero" es: Pero si me desarrollo en un par de estaciones de trabajo? Entonces scp es mucho mejor.

Lo siguiente no funciona con el stash, sino con los cambios no confirmados en el directorio de trabajo. Crea una rama, autocomite todos los cambios actuales, y empuja al control remoto:

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 ..."
}

Use como:

commit_and_push_ my-temp-branch
commit_and_push_

Solo usa Dropbox como lo hizo este tipo. De esa manera no tienes que preocuparte por empujar los escondites ya que todo tu código estaría respaldado.

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