Re: git-p4import.py robustness changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Jun 3, 2007, at 10:54 PM, Shawn O. Pearce wrote:

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/>


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux