2011-01-11 25 views
19

Estoy usando git svn para obtener algo de git bondad con el servidor svn requerido por la compañía. Yo sólo tenía un rebase ir horriblemente mal, y yo "m tratando de averiguar la mejor manera de recuperarRecuperación de una base de datos fallida

Esto es lo que sucedió:.

  1. Para empezar, tuve esta

    ---1 (master) 
        \--B--C--D--E (feature/fix-widgets) 
    
  2. Entonces hice git checkout master y luego git svn rebase en el maestro para eliminar esos commits. No anticipé ningún conflicto entre mi rama de características y el maestro, porque los cambios estaban en una carpeta totalmente diferente. Así que en este punto, creo Tengo esto:

    ---1--2--3--4 (master) 
        \--B--C--D--E (feature/fix-widgets) 
    

    Dónde están 1--2--3--4 commits tiró desde SVN.

  3. Siguiente hago git checkout feature/fix-widgets y luego git rebase master. Inmediatamente surge un conflicto y algunas cosas que no suman, así que decido escabullirme y mirar las cosas con más cuidado. Hago git rebase --abort, esperando que esto me devuelva a donde estaba antes de la rebase.

  4. hago git rebase --abort y recibir el siguiente mensaje de

    $ git rebase --abort 
        error: git checkout-index: unable to create file somedir/somefile.cs (Permission denied) 
        fatal: Could not reset index file to revision 'be44daa05be39f6dd0d602486a598b63b6bd2af7'. 
    
  5. Ahora no estoy seguro de qué hacer. git status muestra que estoy en feature/fix-widgets, pero tengo un montón de etapas cambiadas, y una gran cantidad de archivos sin seguimiento, que se habían confirmado anteriormente. Estaría bien si pudiera volver E.

+1

Me encontré con este mismo problema hoy - Supongo que estabas usando git en Windows, ese encantador sistema operativo que pensaba compartir cerraduras era una buena idea. Mi suposición es que la razón por la que se ahogó en somedir/somefile.cs fue porque estaba abierto en algún lugar ... esta fue la causa de mi falla de la base de datos. Cerrando todos los programas abiertos que pude encontrar, reiniciando según la respuesta elegida, luego rebase, funcionó sin problemas. –

+0

+1 por una pregunta bien escrita que me salvó del llanto. – Tinman

Respuesta

25

Usted debe echar un vistazo a ORIG_HEAD

ORIG_HEAD es estado anterior de HEAD, establecido por los comandos que tienen un comportamiento posiblemente peligroso, para ser fácil de revertirlas.
es menos útil ahora que Git ha reflog: [email protected]{1} es más o menos equivalente a ORIG_HEAD ([email protected]{1} es siempre el último valor de HEAD, ORIG_HEAD es el último valor de HEAD antes de la operación peligrosa)

Así que trate de este git reset para volver antes de cualquier rebase:

git reset --hard ORIG_HEAD 
+0

Bueno, eso fue fácil. Hice un reinicio, y luego solo tontamente intenté volver a establecer la base, y funcionó. * shrug * – notJim

+0

@notJim: cierto, pero puede ser útil tener 'ORIG_HEAD' en cuenta al hacer esos comandos. Puede ser útil. – VonC

Cuestiones relacionadas