On 8/28/07, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote: > > It is not really good. It does not run as fast as git-add && > > git-commit. > > This would be much faster if it was in Perl/Python/Tcl as the script > could avoid two forks per file and instead just fork git-config > once/twice and git-fast-import once. I think those two per-file > forks is what is killing the performance. Yes. I was tempted to rewrite it in C but too lazy. > > But it can swallow big directories that git-add && > > git-commit can't. > > I'm curious, what do you mean by being able to swallow big > directories that git-add/git-commit cannot? Those tools should > not be choking on large directories. What behavior are you seeing > that caused you to decide these tools weren't able to handle a > big directory? I imported a ~1gb directory (including all subdirectories). I don't remember git-add or git-commit that died. It ate all my memory, froze my computer and I had to hard reset the box. > > So I think I would share. It's also simpler than > > those in contrib/fast-import, making it a good start for > > git-fast-import's new users. > > Can you reformat this as a proper patch with a commit message and > resend it? I'd like to include it in contrib/fast-import but would > appreciate a patch with a proper Signed-off-by line before doing so. > > It may also be a good idea to include a note at the top of the > script that it isn't the most efficient frontend, due to the high > shell fork+exec overheads per file. But it is a simple example > that many users can wrap their head around and write something more > suited to their own needs. So its worthwhile to include. OK. Will do. > -- > Shawn. > -- Duy - 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
