Hi, [please Cc me when you reply to my message] On Thu, 22 Nov 2007, Han-Wen Nienhuys wrote: > This one seems to setup a dump of a single branch from the command line, > which then follows the commit structure. Am I missing something? Yes. It should work with "--all", too. In fact, with every rev-list parameters, even a..b (which would cut off the history up to -- and including -- a). > The cool thing about git-fast-import is that it reads from stdin, has a > very easy to use programmatic interface, and does not impose any order > on how you enter the information. > > This doesn't seem to be mirrored by this script? Umm. What exactly do you want to reorder? I mean, this program is meant to dump the complete contents to stdout (whether you redirect it to a file or edit it with sed does not concern this program). It does that. Maybe you want to specify if all blobs should be output first, and then the commits? Or files should be used? But all of these things seem to be useless to me. So I am puzzled what you ask for. > I am working on a script for [company] which uses git. Git is a pain to > script for: for every query I need to invoke another git process, with > another command (log, show-ref, cat-file, show, etc.), parse another > output format and/or specify another --pretty=format:%blah format. Now I am really puzzled. Git is one of the most easily scriptable programs I ever saw. It does not even force you to use certain combinations of scripting languages, such as Python, Scheme, C++ and PostScript, separated by which part of the program you want to script. > Besides being a nuisance, I actually run git on NFS, and every git > process has to go to NFS a couple times to retrieve the same > information. This has a noticeable performance impact. Why don't you just work on a local clone? If it is really performance critical, and I/O is an issue, you are better off working in a tmpfs. Once you're done, you push back to the NFS repository (which is lock-challenged AFAIR, but I guess you know that). > It would make my life a lot easier if I could simply open a pipe to a > single process for the duration of the script, and do all my queries to > this one process. Of course, if the repository is changed by another > process, I would have to restart it, but that's manageable. I could > even write a nice Python class that runs both fast-import and > fast-export. I could then have an efficient Python interface to a > git-repository, without needing any library wrapping. There is a minimal python wrapper to libgit-thin, which was one of our GSoC projects. You might want to look at this if you are really that unhappy with the existing framework. As to the niceness of Python classes; this lies definitely in the eyes of the beholder. For example, I have given up on understanding any part of your GUB framework. Ciao, Dscho - 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
