{"thread":{"id":"9676","subject":"git-import.sh using git-fast-import","startedAt":"2007-08-27T16:13:00Z","lastAt":"2007-08-29T15:20:25Z","messageCount":3,"participants":["Nguyen Thai Ngoc Duy","Johannes Gilger","Nicolas Pitre"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51726","messageId":"fcaeb9bf0708270913o37b2dbdfw2f5f7d89d9ab1d21@mail.gmail.com","threadId":"9676","inReplyTo":null,"subject":"git-import.sh using git-fast-import","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-08-27T16:13:00Z","receivedAt":"2007-08-27T16:13:00Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"It is not really good. It does not run as fast as git-add &&\ngit-commit. But it can swallow big directories that git-add &&\ngit-commit can't. So I think I would share. It's also simpler than\nthose in contrib/fast-import, making it a good start for\ngit-fast-import's new users.\n\nTo run it, move inside the directory you want to import then type\n./git-import.sh master 'your import message'\n-- \nDuy\n"},{"id":"51738","messageId":"46D30D8C.204@hackvalue.de","threadId":"9676","inReplyTo":"fcaeb9bf0708270913o37b2dbdfw2f5f7d89d9ab1d21@mail.gmail.com","subject":"Re: git-import.sh using git-fast-import","fromName":"Johannes Gilger","fromEmail":"heipei@hackvalue.de","sentAt":"2007-08-27T17:44:44Z","receivedAt":"2007-08-27T17:44:44Z","isPatch":false,"sender":{"key":"heipei@hackvalue.de","avatar":"https://avatars.githubusercontent.com/u/6072?v=4"},"body":"Hi,\n\nnice of you to share, but i think the policy on this mailing list is to\ninclude patches (and probably shellscripts like your's) in the message\nitself rather than create a file attachment. I for one find it much more\nconvenient.\n\nregards, jojo\n\nNguyen Thai Ngoc Duy wrote:\n> It is not really good. It does not run as fast as git-add &&\n> git-commit. But it can swallow big directories that git-add &&\n> git-commit can't. So I think I would share. It's also simpler than\n> those in contrib/fast-import, making it a good start for\n> git-fast-import's new users.\n>\n> To run it, move inside the directory you want to import then type\n> ./git-import.sh master 'your import message'\n"},{"id":"51832","messageId":"alpine.LFD.0.999.0708291116310.16727@xanadu.home","threadId":"9676","inReplyTo":"20070829041120.GA25779@coredump.intra.peff.net","subject":"Re: git-import.sh using git-fast-import","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-08-29T15:20:25Z","receivedAt":"2007-08-29T15:20:25Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 29 Aug 2007, Jeff King wrote:\n\n> On Tue, Aug 28, 2007 at 11:47:25PM -0400, Shawn O. Pearce wrote:\n> \n> > Yea, so like the parallel pack-objects experiment that Nico had\n> > done recently we decreased wall-clock time at the expense of using a\n> > larger amount of the system resources.  That is bad as we use more\n> > CPU time than we saved in wallclock time.  Usually a bad tradeoff,\n> > unless you have a realtime requirement you have to meet.\n> \n> It depends. If we all have 64-core processors in a few years, then it\n> might be a better tradeoff.\n\nDepends.  In the experiment I did, I clearly identified flaws showing \nthat the direction was bad and that another approach has to be pursued.  \nThinking in terms of 64-core processors is no excuse for bad designs.\n\n> Of course, some users might want to optimize\n> for wall-clock time, while others want power consumption, etc.\n\nBetter get both at the same time when possible.\n\n\nNicolas\n"}]}