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 

> 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

Reply via email to