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 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
have changed. These files should have been touched each time that a branch is
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
On Jul 10, 2014, at 11:08 AM, Duane Murphy <duanemur...@mac.com> wrote:
> All local storage.
> On Jul 10, 2014, at 11:07 AM, Luke Diamand <l...@diamand.org> wrote:
>> Is this using NFS, or local storage?
>> On 10/07/14 18:30, Bill Door wrote:
>>> $ git p4 sync --detect-branches --import-labels //main@all
>>> ... Lots of useful information elided
>>> fatal: ambiguous argument 'git-p4-tmp/8031': unknown revision or path not in
>>> the working tree.
>>> Use '--' to separate paths from revisions, like this:
>>> 'git <command> [<revision>...] -- [<file>...]'
>>> Command failed: ['git', 'diff-tree',
>>> '6b3ef26a3e2635a5ff0170e15fdadb386672f8b9', 'git-p4-tmp/8031']
>>> If I re-run the command, it works the second time. Of course there are
>>> 73000+ commits. This is gonna take a while.
>>> I've done some debugging. It appears there is a timing problem between
>>> git-p4 and git.
>>> The failure occurs in P4Sync.searchParent(). Even though a checkpoint is
>>> sent to git (for fast-import) just prior to the call to searchParent() in
>>> importChanges(), the file does not yet exist. I used pdb, paused the program
>>> just before the call to diff-tree and the file was missing. After the
>>> program exits due to the error the file exists (i.e. the OS flushed the
>>> file). This is why re-running continues to work, there is an "old" file with
>>> basically the same information laying around (dangerous).
>>> How can I get git (fast-import) to flush the file at the right time?
>>> $ git --version
>>> git version 184.108.40.206
>>> $ python --version
>>> Python 2.6.6
>>> OS: GNU/Linux 2.6.32-431.el6.x86_64
>>> View this message in context:
>>> Sent from the git mailing list archive at Nabble.com.
>>> 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
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