patchgit-p4: Fix support for symlinks.

Detect symlinks as file type, set the git file mode accordingly and strip off the trailing newline in the p4 print output.

Signed-off-by: Simon Hausmann <simon@lst.de>
---
 contrib/fast-import/git-p4 |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

Simon Hausmann <simon@lst.de> writes:

Thanks for a quick fix.

Brian, does this resolve the issue for you? I do not have an access to p4 myself so I won't make a good judge in this area myself. An Ack is appreciated.

Simon, just a style nit.

Every time I see decimal integers 644 and/or 755, it interrupts my flow of thought and forces me to read the change and its surrounding text needlessly carefully.

If you read the code, you can see that this "mode" variable is formatted with ("%d" % mode) for writing out, and is not used as permission bit pattern in any bitwise operations, so you can tell that these constants _are_ safe. But it takes extra efforts to convince yourself that they indeed are.

I would prefer this kind of thing to be written as either:

	mode = 0644
        "%o" % mode

or

	mode = "644"
        "%s" % mode

to make it clear that the author knew what he was doing when he wrote the code.

[Junio C Hamano <gitster@pobox.com>]

Ack.

Looks good here. I can now sync from the p4 tree into git, check out from git and do a clean build, and everything's happy.

Thanks for the quick fix, Simon!

One observation on git-p4 -- it's a little memory hungry when processing large syncs. I haven't tried incremental syncs on top of the initial one though -- if it's only the initial that's expensive it's not that big a deal.

It seemed to top out around 988MB resident. The branch I was importing is about 562MB when checked out and the resulting git repository is about 175MB.

Brian

Brian Swetland wrote:

While importing each change, I think git-p4 puts into memory two copies of the contents of all changed files, one in p4CmdList and one in readP4Files. (That's the raw contents, not just the delta.) I don't think there's any fundamental reason it couldn't stream them instead.

So incremental syncs may or may not take less memory. If the first change imports a huge project and no subsequent change ever touches all those files at once, then yeah. But if, say, you periodically change the copyright dates in all files in the repository, you'll have this memory usage whenever syncing such a change.

As long as we're listing git-p4 complaints, here are a couple of mine:

1) coding style. *self-nag* Simon Hausmann mentioned he was happy to 
accept patches...and I made one up a while ago; I just need to do a 
merge and final check that I haven't broken anything before sending it off.

2) it breaks on tempfile purges. My previous employer has these in their 
repository, and I think for the moment they're working around it by 
treating a "purge" as a "delete". If I read the Perforce documentation 
right, though, only the latest version of a tempfile's contents is kept 
in the repository anyway. Their history can't be captured accurately, so 
the proper thing is probably to omit tempfiles entirely. (And deleting 
files when they become tempfiles and creating files when they become a 
normal type.)

Best regards, Scott