Archivos de escenario, luego agregar de forma remota, luego tirar - y mis archivos se han ido

Question

Parece que he perdido el trabajo de mi tarde en un nuevo repositorio. Esto es lo que hice:

1. Creé un nuevo proyecto localmente e hice algún trabajo.
2. Creado un acuerdo de recompra en github
3. git init
4. git add src
5. git remote add origin git@github.com:Synesso/memx.git
6. git pull origin master
7. git add .gitignore
8. git commit -m 'updated ignore'
9. git push origin master

Tanto mi repositorio local como el repositorio github solo tienen dos compromisos. La confirmación inicial (hecha por github en la creación del proyecto) y una segunda que incluye solo el archivo .gitignore.

Los archivos agregados en el paso 4 (git add src) no están presentes. Tampoco parecen ser escenificados.

¿Pierde archivos por etapas cuando hace un git pull? ¿Puedo recuperarlos de alguna manera?

Estado actual:

$ git status 
# On branch master 
nothing to commit (working directory clean) 

Mi inital add no está en el reflog.

$ git reflog 
c80135d HEAD@{0}: checkout: moving from 999d128ea4e6969f9eacbceebb5f857f2aa5abb0 to master 
999d128 HEAD@{1}: checkout: moving from master to HEAD~1 
c80135d HEAD@{2}: checkout: moving from 999d128ea4e6969f9eacbceebb5f857f2aa5abb0 to master 
999d128 HEAD@{3}: checkout: moving from master to 999d128ea4e6969f9eacbceebb5f857f2aa5abb0 
c80135d HEAD@{4}: commit (amend): updated ignore 
28b4f90 HEAD@{5}: commit: updated ignore 
999d128 HEAD@{6}: initial pull 

history muestra que añadí la carpeta src, pero no lo cometió:

223 git init 
225 git add src 
229 git add project/Build.scala 
234 git remote add origin git@github.com:Synesso/memx.git 
250 git pull origin master 

sé git se quejará si intenta tirar con archivos sucios presentes. ¿Pero está bien hacer un tirón que obliterará los archivos escalonados? Eso parece incorrecto

---

Acabo de volver a probar este proceso y sí, destruye los archivos por etapas.

jem@jem-usb:~/projects$ mkdir x 
jem@jem-usb:~/projects$ cd x 
jem@jem-usb:~/projects/x$ git init 
Initialized empty Git repository in /home/jem/projects/x/.git/ 
jem@jem-usb:~/projects/x$ echo "hi" > hello.world 
jem@jem-usb:~/projects/x$ git add hello.world 
jem@jem-usb:~/projects/x$ git status 
# On branch master 
# 
# Initial commit 
# 
# Changes to be committed: 
# (use "git rm --cached <file>..." to unstage) 
# 
#  new file: hello.world 
# 
jem@jem-usb:~/projects/x$ ls -asl 
total 24 
4 drwxrwxr-x 3 jem jem 4096 Apr 28 20:56 . 
4 drwxr-xr-x 8 jem jem 4096 Apr 28 20:56 .. 
4 drwxrwxr-x 7 jem jem 4096 Apr 28 20:56 .git 
12 -rw-rw-r-- 1 jem jem 3 Apr 28 20:56 hello.world 
jem@jem-usb:~/projects/x$ git remote add origin git@github.com:Synesso/memx.git 
jem@jem-usb:~/projects/x$ git reflog 
fatal: bad default revision 'HEAD' 
jem@jem-usb:~/projects/x$ git pull origin master 
remote: Counting objects: 7, done. 
remote: Compressing objects: 100% (5/5), done. 
remote: Total 7 (delta 0), reused 3 (delta 0) 
Unpacking objects: 100% (7/7), done. 
From github.com:Synesso/memx 
* branch   master  -> FETCH_HEAD 
jem@jem-usb:~/projects/x$ ls -asl 
total 36 
4 drwxrwxr-x 3 jem jem 4096 Apr 28 20:53 . 
4 drwxr-xr-x 8 jem jem 4096 Apr 28 20:52 .. 
4 drwxrwxr-x 8 jem jem 4096 Apr 28 20:53 .git 
12 -rw-rw-r-- 1 jem jem 59 Apr 28 20:53 .gitignore 
12 -rw-rw-r-- 1 jem jem 9 Apr 28 20:53 README.md 
jem@jem-usb:~/projects/x$ git reflog 
c80135d HEAD@{0}: initial pull 

Se eliminó el archivo hello.world sin previo aviso.

Answer 1

que era capaz de reproducir esto sin usar GitHub, utilizando dos anfitriones (rebautizado aquí como sistppalB, que es la "distancia", y sistppalA, que es el "local"):

hostB$ cd /tmp; mkdir repo; cd repo; git init 
Initialized empty Git repository in /tmp/repo/.git/ 
hostB$ : > .gitignore; echo this is a readme > README.md 
hostB$ git add .; git commit -m initial 
[master (root-commit) 58d43bd] initial 
1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 .gitignore 
create mode 100644 README.md 

hostA$ cd /tmp; mkdir repo; cd repo; git init 
Initialized empty Git repository in /tmp/repo/.git/ 
hostA$ echo hi > hello.world 
hostA$ git add hello.world 
hostA$ git status 
# On branch master 
# 
# Initial commit 
# 
# Changes to be committed: 
# (use "git rm --cached <file>..." to unstage) 
# 
# new file: hello.world 
# 
hostA$ git remote add origin ssh://hostB.dom.ain/tmp/repo 
hostA$ git pull origin master 
remote: Counting objects: 4, done. 
remote: Compressing objects: 100% (2/2), done. 
remote: Total 4 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (4/4), done. 
From ssh://hostB.dom.ain/tmp/repo 
* branch   master  -> FETCH_HEAD 
hostA$ ls 
README.md 

Importante : puede utilizar git fsck --lost-found para recuperar sus archivos por etapas:

hostA$ git fsck --lost-found 
Checking object directories: 100% (256/256), done. 
dangling blob 45b983be36b73c0788dc9cbcb76cbb80fc7bb057 
hostA$ 

y por supuesto, si se examina la burbuja (s) (que ahora se restauró en .git/lost-found/other), los que tendrán su materia perdida. (Sin embargo, cualquier estructura de directorio se habrá borrado, y deberá averiguar qué archivo es y volver a ponerlos donde los quiere).

Curiosamente, si git fetch origin seguido de , toma la inicial del origen revisiones (con los archivos .gitignore y README.md de hostB, en este caso) y conserva sus "cambios para comprometerse". ¿Otra razón para favorecer git fetch seguido de git merge? :-)

Answer 2

Su repositorio en github no contiene ningún archivo valioso. ¿No te olvidaste de cometerlos?

Incluso si no están en etapas, ¿dónde está su carpeta srclocalmente? Si solo hiciste lo que se especifica en la pregunta, git no podría comer tus archivos de todos modos.

Answer 3

creo que debe guardar los cambios de local después de add antes remote add y pull

1. git init
2. git add src
3. git add .gitignore
4. git commit -m 'actualiza ignorar'
5. git remote agregar origen git@github.com: Synesso/memx.git
6. git tirar de origen maestro
7. git push origin master

Answer 4

Creo que este es un efecto secundario desgracia de tener un nuevo repositorio w/o una única confirmación. Si intenta su prueba de nuevo, pero en lugar de realizar localmente:

git init; echo "Readme" > Readme; git add Readme; git commit -m 'Initial commit' 

entonces cuando 'pull' en un directorio de trabajo con los archivos de 'origen', GIT advertirá y, más importante, no eliminará la materia.

Answer 5

que recibió la siguiente respuesta en la lista de correo de git Junio ​​Hamano:

---

Es un caso no previsto esquina interferir nuestro intento de ser demasiado agradable que salió por la culata.

Durante mucho tiempo, al no tener la historia y pidiendo a tirar estaba prohibido, porque "git pull" es se trata de la combinación de dos (o más) historiales juntos y tirar cuando no se tiene la historia es un disparate --- usted solo tiene un historial (el historial del otro lado) y no hay nada que combinar.

Más tarde nos trataron de ser más agradable, ya que algunos nuevos usuarios desencadenan un error cuando hacer "git init" en un directorio vacío, seguido de "git pull", por redefinición de "fusionar" en ninguna historia en el sentido de restablecer la otra historia.

Este "git init & & git pull" resuelto, pero no anticipó a nadie haría un "init git & & git add & tirón & git" secuencia, a la que hay ningún resultado en su sano juicio que no sea sólo error de salida.

Un parche para dar ese único resultado razonable puede verse así.

git-pull.sh | 3 +++ 
1 file changed, 3 insertions(+) 

diff --git a/git-pull.sh b/git-pull.sh 
index 2a10047..da102d0 100755 
--- a/git-pull.sh 
+++ b/git-pull.sh 
@@ -261,6 +261,9 @@ esac 

if test -z "$orig_head" 
then 
+  test $(git ls-files | wc -l) = 0 || 
+  die "$(gettext "Uncommitted changes in the index")" 
+ 
     git update-ref -m "initial pull" HEAD $merge_head "$curr_head" && 
     git read-tree -m -u HEAD || exit 1 
     exit