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
>> from Perforce. As part of my experiments to figure out this problem, I
>> 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
>> Then I have to start the 8-12 hour process over again (did I mention 70k
> 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 v220.127.116.11, 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