Re: git-p4import.py robustness changes
- From
- Scott Lamb <slamb@slamb.org>
- Date
- Jun 4, 2007, 07:19 UTC
- Message-ID
- <99C09A45-EACF-43C0-8EF6-85450B109BF6@slamb.org>
- In-Reply-To
- <20070604055433.GD4507@spearce.org>
On Jun 3, 2007, at 10:54 PM, Shawn O. Pearce wrote:
Show 6 quoted lines
> I think writing data to fast-import is much easier than running > the raw Git commands, especially when you are talking about an > import engine where you need to set all of the special environment > variables for git-commit-tree or git-tag to do its job properly. > Its a good tool that simply doesn't get enough use, partly because > nobody is using it...
Yeah, I'm sold. I read git-p4 more thoroughly and tried it out...it's pretty nice. The P4Sync command has a simpler, more trustworthy flow than git-p4import.py.
On the Perforce side, I particularly like the use of "p4 print" to grab the files instead of "p4 sync". It avoids playing weird games with the client - I think nothing good can come of git-p4import.py's "p4 sync -k" and symlinks to map multiple branches into the same directory, which is not the Perforce way. Makes me nervous that what's submitted to git won't be the same as what's in the Perforce depot.
I would have thought launching a "p4 print" on each file would be horribly slow with the network latency of each request, but...well, apparently not.
Maybe I'll work up git-p4 patches for subcommand error handling, like my git-p4import.py ones. And fix some style - seriously, who puts semicolons at the end of Python commands? *grumble*
Best regards, Scott
-- Scott Lamb <http://www.slamb.org/>