On Jul 12, 2014, at 11:10 AM, Pete Wyckoff <p...@padd.com> wrote: >> Some additional investigation. >> >> I am working in a copy of a repository that was originally used to pull the >> data >> from Perforce. As part of my experiments to figure out this problem, I >> deleted >> the contents of .git/git-p4-tmp/. >> >> I noticed that git-p4 would continue if those files were present. I have now >> copied the files that were in .git/git-p4-tmp/ from the other repository. >> >> git-p4 is not crashing now, but I also noticed that none of the dates on >> these files >> have changed. These files should have been touched each time that a branch >> is taken, >> but these files have not changed while the sync is running. >> >> That seems significant. >> >> I expect git-p4 to crash again on a new commit that is not in >> .git/git-p4-tmp/. >> Then I have to start the 8-12 hour process over again (did I mention 70k >> commits?). > > Bizarre. That directory is really supposed to be temporary, and > live only during a single git p4 invocation. It's just a bunch > of branch heads for the temporary commits. I don't know why > those branches, and the git-p4-tmp directory, hang around after > you run git p4. Might be worth your investigation.
The reason the files are still there is because git-p4 crashes (exits with an error) and doesn't clean them up. When git-p4 exits cleanly, the directory is fine. My experience is that git-p4 exists abnormally often enough. > The second weirdness is why a new run doesn't create the branch. > This maybe points to self.checkpoint() not really checkpointing. > It does send a "checkpoint" down the git fast-import stream, > which is supposed to make it write the branches out. You might > consider grabbing the fast-import process in a debugger and see > why it's not writing out the branch head. I started looking at the code for fast-import. There's a lot of code there, so didn't go down that path. I've posted another message indicating that I sincerely believe the problem is in git-fast-import. My current working theory is that because the file matches another commit (that's the point of writing the commit) git-fast-import doesn't flush the file. I've clearly stopped git-p4 immediately after the checkpoint and there is no file. When the program exits (abnormally of course), the file appears (thanks to the file system). Seems like a flush problem somewhere. I was hoping someone who knows git-fast-import would have a clue as to the problem. > There's lots of changes since v1.7.12.4, but nothing obvious I > can see that would cause this. Sorry, Thanks for taking a look. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
