¿Debería Git alguna vez pensar que un archivo que obtuvo de un tirón ahora no se ha rastreado?

Question

Uno de nuestros desarrolladores sigue teniendo problemas con sus repositorios Git. Él tira y luego el "estado de git" muestra una lista completa de archivos sin seguimiento (es decir, Git cree que son nuevos) que en realidad provienen de su última extracción. En realidad, puede volver a través de su registro de git y especificar el compromiso particular que los agregó y está en su historial. Sin embargo, si vas a uno de los archivos ahora sin seguimiento y haces un registro de git en él, no hay ningún historial.

Estoy absolutamente desconcertado. Todos en el grupo, incluyéndome a mí, somos nuevos en Git, así que no puedo descartar que pueda estar cometiendo un error en alguna parte, pero parece poco probable. Es como si su repositorio se estuviera volviendo corrupto.

Está usando msysgit 1.7.6 y Tortoise Git 1.7.3. Estábamos usando eGit con myEclipse por un tiempo y se bloqueó repetidamente, por lo que se culpó a los primeros problemas. Ahora, no creo que nadie lo esté usando más, así que no siento que pueda culpar a eGit por más tiempo.

¡Necesito la ayuda de los gurús de Git de Stack Overflow! ¿Qué podría estar causando esto? ¿Hay alguna circunstancia bajo la cual esto sería normal?

Por la petición, aquí es el archivo .git/config para el repositorio que se convirtió en corrompido:

[core] 
    repositoryformatversion = 0 
    filemode = false 
    bare = false 
    logallrefupdates = true 
    symlinks = false 
    ignorecase = true 
    hideDotFiles = dotGitOnly 
[remote "origin"] 
    fetch = +refs/heads/*:refs/remotes/origin/* 
    url = G:\\DotcomB 
    puttykeyfile = 
[branch "master"] 
    remote = origin 
    merge = refs/heads/master 
[user] 
    name = jsmith 
    email = JoeSmith@somewhere.com 

Answer 1

nunca lo hicimos "resolver" este problema. Sin embargo, dejamos de usar un directorio remoto para almacenar los repositorios compartidos. Nunca funcionó bien, estaba usando Novell o alguna solución de red de Windows que era tan lenta como la diana, y regularmente vimos problemas de un tipo u otro.

Ahora, no puedo demostrar que la configuración inusual fue la causa de todos nuestros problemas, pero , me GitBlit configuración como servidor Git podríamos hablar con su lugar. Después de hacerlo, cada acción que tomamos con el servidor fue, literalmente, un orden de magnitud más rápido y nunca volvimos a ver el problema de la corrupción.

Answer 2

Ver si la variable de entorno git-dir se ha cambiado. Del mismo modo, la variable del árbol de trabajo. También vea si en realidad está en el mismo directorio de lo que piensa. Está utilizando tortoisegit y puede ser un directorio diferente al que está mirando frente a la línea de comando.

Además, cuando realice una copia de seguridad en el archivo para ver si está allí, asegúrese de completar los nombres de los directorios, ya que msysgit se complace en tratar el archivo/directorio independientemente de la carcasa. Git, sin embargo se preocupa.

mydir/somefile 

se puede llegar por

cd MYDIR 

y el camino reflejará eso.

Ahora el estado de git mostrará que hay un archivo que no se rastrea porque git verá mydir/somefile como algo diferente de MYDIR/somefile. A veces es difícil de ver porque todo lo que se necesita es una diferencia de caso en la ruta completa a un archivo para obtener este comportamiento.

Limítese a la línea de comandos por ahora para resolver esto. Rebotar entre tortoisegit y la línea de comando no podría ayudar a la situación.

¿Puede iniciar un nuevo repositorio y ver si se puede reproducir solo en la línea de comandos?

Espero que esto ayude,

Adam