{"thread":{"id":"10948","subject":"[WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","startedAt":"2007-11-21T03:40:37Z","lastAt":"2007-11-27T15:10:41Z","messageCount":27,"participants":["Johannes Schindelin","Johannes Sixt","Shawn O. Pearce","Geert Bosch","Andreas Ericsson","Han-Wen Nienhuys","Nguyen Thai Ngoc Duy","Karl Hasselström"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"60451","messageId":"Pine.LNX.4.64.0711210336210.27959@racer.site","threadId":"10948","inReplyTo":null,"subject":"[WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-21T03:40:37Z","receivedAt":"2007-11-21T03:40:37Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\n[WIP: this does not handle tags yet, and it lacks a test script\n as well as documentation.]\n\nThis program dumps (parts of) a git repository in the format that\nfast-import understands.\n\nFor clarity's sake, it does not use the 'inline' method of specifying\nblobs in the commits, but builds the blobs before building the commits.B\n\n---\n\tI am way too tired now to continue, but maybe someone else wants\n\tto pick up the ball.\n\n\tOh, and it relies on \"int\" being castable to void * and vice \n\tversa. Is anybody aware of a platform where this can lead to\n\tproblems?\n\n\tAnd yes, I will add a copyright when I woke up again.\n\n .gitignore | 1 +\n Makefile | 1 +\n builtin-fast-export.c | 202 +++++++++++++++++++++++++++++++++++++++++++++++++\n builtin.h | 1 +\n git.c | 1 +\n 5 files changed, 206 insertions(+), 0 deletions(-)\n create mode 100755 builtin-fast-export.c\n\ndiff --git a/.gitignore b/.gitignore\nindex 507e351..ef69e2f 100644\n--- a/.gitignore\n+++ b/.gitignore\n@@ -35,6 +35,7 @@ git-diff-files\n git-diff-index\n git-diff-tree\n git-describe\n+git-fast-export\n git-fast-import\n git-fetch\n git-fetch--tool\ndiff --git a/Makefile b/Makefile\nindex dd3ba6f..8784eff 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -336,6 +336,7 @@ BUILTIN_OBJS = \\\n \tbuiltin-diff-files.o \\\n \tbuiltin-diff-index.o \\\n \tbuiltin-diff-tree.o \\\n+\tbuiltin-fast-export.o \\\n \tbuiltin-fetch.o \\\n \tbuiltin-fetch-pack.o \\\n \tbuiltin-fetch--tool.o \\\ndiff --git a/builtin-fast-export.c b/builtin-fast-export.c\nnew file mode 100755\nindex 0000000..2e8e3dd\n--- /dev/null\n+++ b/builtin-fast-export.c\n@@ -0,0 +1,202 @@\n+#include \"builtin.h\"\n+#include \"cache.h\"\n+#include \"commit.h\"\n+#include \"object.h\"\n+#include \"tag.h\"\n+#include \"diff.h\"\n+#include \"diffcore.h\"\n+#include \"log-tree.h\"\n+#include \"revision.h\"\n+#include \"decorate.h\"\n+#include \"path-list.h\"\n+\n+static struct decoration idnums;\n+static uint32_t last_idnum;\n+\n+static const char *fast_export_usage = \"git-fast-export [rev-list-opts]\";\n+\n+static int has_unshown_parent(struct commit *commit)\n+{\n+\tstruct commit_list *parent;\n+\n+\tfor (parent = commit->parents; parent; parent = parent->next)\n+\t\tif (!(parent->item->object.flags & SHOWN))\n+\t\t\treturn 1;\n+\treturn 0;\n+}\n+\n+static void handle_object(const unsigned char *sha1)\n+{\n+\tunsigned long size;\n+\tenum object_type type;\n+\tchar *buf;\n+\tstruct object *object;\n+\n+\tif (is_null_sha1(sha1))\n+\t\treturn;\n+\n+\tobject = parse_object(sha1);\n+\tif (!object)\n+\t\tdie (\"Could not read blob %s\", sha1_to_hex(sha1));\n+\n+\tif (object->flags & SHOWN)\n+\t\treturn;\n+\n+\tbuf = read_sha1_file(sha1, &type, &size);\n+\tif (!buf)\n+\t\tdie (\"Could not read blob %s\", sha1_to_hex(sha1));\n+\n+\tlast_idnum++;\n+\tadd_decoration(&idnums, object, (void *)last_idnum);\n+\n+\tprintf(\"blob\\nmark :%d\\ndata %lu\\n\", last_idnum, size);\n+\tif (fwrite(buf, size, 1, stdout) != 1)\n+\t\tdie (\"Could not write blob %s\", sha1_to_hex(sha1));\n+\tprintf(\"\\n\");\n+\n+\tobject->flags |= SHOWN;\n+\tfree(buf);\n+}\n+\n+static void show_filemodify(struct diff_queue_struct *q,\n+\t\tstruct diff_options *options, void *data)\n+{\n+\tint i;\n+\tfor (i = 0; i < q->nr; i++) {\n+\t\tstruct diff_filespec *spec = q->queue[i]->two;\n+\t\tif (is_null_sha1(spec->sha1))\n+\t\t\tprintf(\"D %s\\n\", spec->path);\n+\t\telse {\n+\t\t\tstruct object *object = lookup_object(spec->sha1);\n+\t\t\tprintf(\"M 0%06o :%d %s\\n\", spec->mode,\n+\t\t\t\t\t(int)lookup_decoration(&idnums, object),\n+\t\t\t\t\tspec->path);\n+\t\t}\n+\t}\n+}\n+\n+static void handle_commit(struct commit *commit, struct rev_info *rev)\n+{\n+\tconst char *author, *author_end, *committer, *committer_end, *message;\n+\tint saved_output_format = rev->diffopt.output_format;\n+\tint i;\n+\n+\trev->diffopt.output_format = DIFF_FORMAT_CALLBACK;\n+\n+\tparse_commit(commit);\n+\tauthor = strstr(commit->buffer, \"\\nauthor \");\n+\tif (!author)\n+\t\tdie (\"Could not find author in commit %s\",\n+\t\t\t\tsha1_to_hex(commit->object.sha1));\n+\tauthor++;\n+\tauthor_end = strchrnul(author, '\\n');\n+\tcommitter = strstr(author_end, \"\\ncommitter \");\n+\tif (!committer)\n+\t\tdie (\"Could not find committer in commit %s\",\n+\t\t\t\tsha1_to_hex(commit->object.sha1));\n+\tcommitter++;\n+\tcommitter_end = strchrnul(committer, '\\n');\n+\tmessage = strstr(committer_end, \"\\n\\n\");\n+\tif (message)\n+\t\tmessage += 2;\n+\n+\tif (commit->parents) {\n+\t\tparse_commit(commit->parents->item);\n+\t\tdiff_tree_sha1(commit->parents->item->tree->object.sha1,\n+\t\t\t\tcommit->tree->object.sha1, \"\", &rev->diffopt);\n+\t}\n+\telse\n+\t\tdiff_root_tree_sha1(commit->tree->object.sha1,\n+\t\t\t\t\"\", &rev->diffopt);\n+\n+\tfor (i = 0; i < diff_queued_diff.nr; i++)\n+\t\thandle_object(diff_queued_diff.queue[i]->two->sha1);\n+\n+\tlast_idnum++;\n+\tadd_decoration(&idnums, &commit->object, (void *)last_idnum);\n+\tprintf(\"commit %s\\nmark :%d\\n%.*s\\n%.*s\\ndata %u\\n%s\",\n+\t\t(const char *)commit->util, last_idnum,\n+\t\tauthor_end - author, author,\n+\t\tcommitter_end - committer, committer,\n+\t\tmessage ? strlen(message) : 0, message ? message : \"\");\n+\n+\tlog_tree_diff_flush(rev);\n+\trev->diffopt.output_format = saved_output_format;\n+\n+\tprintf(\"\\n\");\n+}\n+\n+static void handle_tail(struct object_array *commits, struct rev_info *revs)\n+{\n+\tstruct commit *commit;\n+\twhile (commits->nr) {\n+\t\tcommit = (struct commit *)commits->objects[commits->nr - 1].item;\n+\t\tif (has_unshown_parent(commit))\n+\t\t\treturn;\n+\t\thandle_commit(commit, revs);\n+\t\tcommits->nr--;\n+\t}\n+}\n+\n+int cmd_fast_export(int argc, const char **argv, const char *prefix)\n+{\n+\tstruct rev_info revs;\n+\tstruct object_array commits = { 0, 0, NULL };\n+\tstruct path_list extra_refs = { NULL, 0, 0, 0 };\n+\tstruct commit *commit;\n+\tint i;\n+\n+\tinit_revisions(&revs, prefix);\n+\targc = setup_revisions(argc, argv, &revs, NULL);\n+\tif (argc > 1)\n+\t\tusage (fast_export_usage);\n+\n+\tfor (i = 0; i < revs.pending.nr; i++) {\n+\t\tstruct object_array_entry *e = revs.pending.objects + i;\n+\t\tunsigned char sha1[20];\n+\t\tchar *full_name;\n+\n+\t\t/* TODO: handle tags */\n+\t\tcommit = (struct commit *)e->item;\n+\t\tif (dwim_ref(e->name, strlen(e->name), sha1, &full_name) != 1)\n+\t\t\tdie (\"Could not get a unique ref name for '%s'\",\n+\t\t\t\te->name);\n+\t\tif (commit->util)\n+\t\t\t/* more than one name for the same object */\n+\t\t\tpath_list_insert(full_name, &extra_refs)->util = commit;\n+\t\telse\n+\t\t\tcommit->util = full_name;\n+\t}\n+\n+\tprepare_revision_walk(&revs);\n+\trevs.diffopt.format_callback = show_filemodify;\n+\trevs.diffopt.recursive = 1;\n+\twhile ((commit = get_revision(&revs))) {\n+\t\tif (has_unshown_parent(commit)) {\n+\t\t\tstruct commit_list *parent = commit->parents;\n+\t\t\tadd_object_array(&commit->object, NULL, &commits);\n+\t\t\tfor (; parent; parent = parent->next)\n+\t\t\t\tif (!parent->item->util)\n+\t\t\t\t\tparent->item->util = commit->util;\n+\t\t}\n+\t\telse {\n+\t\t\thandle_commit(commit, &revs);\n+\t\t\thandle_tail(&commits, &revs);\n+\t\t}\n+\t}\n+\n+\tif (commits.nr)\n+\t\tdie (\"This should not happen: there were %d commits left!\",\n+\t\t\tcommits.nr);\n+\n+\tfor (i = 0; i < extra_refs.nr; i++) {\n+\t\t/* create refs pointing to already seen commits */\n+\t\tcommit = extra_refs.items[i].util;\n+\t\tprintf(\"reset %s\\nfrom :%d\\n\\n\",\n+\t\t\t\textra_refs.items[i].path,\n+\t\t\t\t(int)lookup_decoration(&idnums,\n+\t\t\t\t\t&commit->object));\n+\t}\n+\n+\treturn 0;\n+}\ndiff --git a/builtin.h b/builtin.h\nindex e76f5da..5723f9e 100644\n--- a/builtin.h\n+++ b/builtin.h\n@@ -31,6 +31,7 @@ extern int cmd_diff_files(int argc, const char **argv, const char *prefix);\n extern int cmd_diff_index(int argc, const char **argv, const char *prefix);\n extern int cmd_diff(int argc, const char **argv, const char *prefix);\n extern int cmd_diff_tree(int argc, const char **argv, const char *prefix);\n+extern int cmd_fast_export(int argc, const char **argv, const char *prefix);\n extern int cmd_fetch(int argc, const char **argv, const char *prefix);\n extern int cmd_fetch_pack(int argc, const char **argv, const char *prefix);\n extern int cmd_fetch__tool(int argc, const char **argv, const char *prefix);\ndiff --git a/git.c b/git.c\nindex 0b6825e..deda6dd 100644\n--- a/git.c\n+++ b/git.c\n@@ -301,6 +301,7 @@ static void handle_internal_command(int argc, const char **argv)\n \t\t{ \"diff-files\", cmd_diff_files },\n \t\t{ \"diff-index\", cmd_diff_index, RUN_SETUP },\n \t\t{ \"diff-tree\", cmd_diff_tree, RUN_SETUP },\n+\t\t{ \"fast-export\", cmd_fast_export, RUN_SETUP },\n \t\t{ \"fetch\", cmd_fetch, RUN_SETUP },\n \t\t{ \"fetch-pack\", cmd_fetch_pack, RUN_SETUP },\n \t\t{ \"fetch--tool\", cmd_fetch__tool, RUN_SETUP },\n-- \n1.5.3.5.1751.gf6fb4\n"},{"id":"60477","messageId":"4743E1D6.4010308@viscovery.net","threadId":"10948","inReplyTo":"Pine.LNX.4.64.0711210336210.27959@racer.site","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-11-21T07:44:22Z","receivedAt":"2007-11-21T07:44:22Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin schrieb:\n> \tOh, and it relies on \"int\" being castable to void * and vice \n> \tversa. Is anybody aware of a platform where this can lead to\n> \tproblems?\n\nWin64?\n\n-- Hannes\n"},{"id":"60478","messageId":"20071121074714.GW14735@spearce.org","threadId":"10948","inReplyTo":"4743E1D6.4010308@viscovery.net","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-11-21T07:47:14Z","receivedAt":"2007-11-21T07:47:14Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Sixt wrote:\n> Johannes Schindelin schrieb:\n> >\tOh, and it relies on \"int\" being castable to void * and vice \n> >\tversa. Is anybody aware of a platform where this can lead to\n> >\tproblems?\n> \n> Win64?\n\nDoes anyone even use that? I thought that was dead. Like Vista.\n\nSeriously though, we include stdint.h. If you want to cast a void*\nto an integer type and back use ptrint_t. That's what it exists for.\n\n-- \nShawn.\n"},{"id":"60504","messageId":"2348F06A-F9A2-4A8F-8501-D0B696F34388@adacore.com","threadId":"10948","inReplyTo":"Pine.LNX.4.64.0711210336210.27959@racer.site","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Geert Bosch","fromEmail":"bosch@adacore.com","sentAt":"2007-11-21T12:43:43Z","receivedAt":"2007-11-21T12:43:43Z","isPatch":true,"sender":{"key":"bosch@adacore.com","avatar":null},"body":"\nOn Nov 20, 2007, at 22:40, Johannes Schindelin wrote:\n> \tOh, and it relies on \"int\" being castable to void * and vice\n> \tversa. Is anybody aware of a platform where this can lead to\n> \tproblems?\n\nLike any 64-bit system? int is 32 bit and void * is 64.\nSo, casting a pointer to an int drops half the bits.\nWhen you convert it back it will point to a funny place...\n\n -Geert\n"},{"id":"60514","messageId":"Pine.LNX.4.64.0711211209080.27959@racer.site","threadId":"10948","inReplyTo":"4743E1D6.4010308@viscovery.net","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-21T14:01:00Z","receivedAt":"2007-11-21T14:01:00Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 21 Nov 2007, Johannes Sixt wrote:\n\n> Johannes Schindelin schrieb:\n> > \tOh, and it relies on \"int\" being castable to void * and vice versa.\n> > Is anybody aware of a platform where this can lead to problems?\n> \n> Win64?\n\nIs this really a problem? I mean, all I need is that i == (int)(void *)i.\n\nMy doubts came from platforms where you can access memory only aligned to \n4-byte chunks, and that it _may_ be possible that some of them do not even \nstore the least significant two bits.\n\nCiao,\nDscho\n\nP.S.: I'll try to read up on ptrint_t, as suggested by Shawn.\n"},{"id":"60520","messageId":"Pine.LNX.4.64.0711211441000.27959@racer.site","threadId":"10948","inReplyTo":"2348F06A-F9A2-4A8F-8501-D0B696F34388@adacore.com","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-21T14:42:06Z","receivedAt":"2007-11-21T14:42:06Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 21 Nov 2007, Geert Bosch wrote:\n\n> On Nov 20, 2007, at 22:40, Johannes Schindelin wrote:\n> > \tOh, and it relies on \"int\" being castable to void * and vice\n> > \tversa. Is anybody aware of a platform where this can lead to\n> > \tproblems?\n> \n> Like any 64-bit system? int is 32 bit and void * is 64. So, casting a \n> pointer to an int drops half the bits. When you convert it back it will \n> point to a funny place...\n\nHave you even read the patch? Like I pointed out in my reply to Hannes, I \nonly need the guarantee that\n\n\ti == (int)(void *)i\n\nfor all integers i.\n\nCiao,\nDscho\n"},{"id":"60523","messageId":"47444A1B.4000907@op5.se","threadId":"10948","inReplyTo":"Pine.LNX.4.64.0711211209080.27959@racer.site","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-21T15:09:15Z","receivedAt":"2007-11-21T15:09:15Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> \n> P.S.: I'll try to read up on ptrint_t, as suggested by Shawn.\n\nI can't find a reference to ptrint_t anywhere on either my system,\nand the 10 first hits on Google finds it on typedef lines, most\ncommonly like this:\n\n\ttypedef unsigned long ptrint_t;\n\n\nI think ptrdiff_t is more portable. Here's the relevant entry\nabout ptrdiff_t from /usr/include/obstack.h on my system:\n\n---%<---%<---%<---\n/* We need the type of a pointer subtraction. If __PTRDIFF_TYPE__ is\n defined, as with GNU C, use that; that way we don't pollute the\n namespace with 's symbols. Otherwise, include \n and use ptrdiff_t. */\n\n#ifdef __PTRDIFF_TYPE__\n# define PTR_INT_TYPE __PTRDIFF_TYPE__\n#else\n# include \n# define PTR_INT_TYPE ptrdiff_t\n#endif\n---%<---%<---%<---\n\nMySQL seems to have botched that one though. It has this instead:\n\n\ttypedef long my_ptrdiff_t;\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"60530","messageId":"Pine.LNX.4.64.0711211546410.27959@racer.site","threadId":"10948","inReplyTo":"47444A1B.4000907@op5.se","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-21T15:47:15Z","receivedAt":"2007-11-21T15:47:15Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 21 Nov 2007, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> > \n> > P.S.: I'll try to read up on ptrint_t, as suggested by Shawn.\n> \n> I can't find a reference to ptrint_t anywhere on either my system,\n> and the 10 first hits on Google finds it on typedef lines, most\n> commonly like this:\n> \n> \ttypedef unsigned long ptrint_t;\n\nIt is really called intptr_t, and it is C99.\n\nCiao,\nDscho\n"},{"id":"60531","messageId":"47445493.9000806@op5.se","threadId":"10948","inReplyTo":"Pine.LNX.4.64.0711211546410.27959@racer.site","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-21T15:53:55Z","receivedAt":"2007-11-21T15:53:55Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 21 Nov 2007, Andreas Ericsson wrote:\n> \n>> Johannes Schindelin wrote:\n>>> P.S.: I'll try to read up on ptrint_t, as suggested by Shawn.\n>> I can't find a reference to ptrint_t anywhere on either my system,\n>> and the 10 first hits on Google finds it on typedef lines, most\n>> commonly like this:\n>>\n>> \ttypedef unsigned long ptrint_t;\n> \n> It is really called intptr_t, and it is C99.\n> \n\nThat'd explain it I guess. Thanks for the clarification.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"60726","messageId":"fi5743$32p$1@ger.gmane.org","threadId":"10948","inReplyTo":"Pine.LNX.4.64.0711210336210.27959@racer.site","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-11-23T00:27:46Z","receivedAt":"2007-11-23T00:27:46Z","isPatch":true,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Johannes Schindelin escreveu:\n> [WIP: this does not handle tags yet, and it lacks a test script\n> as well as documentation.]\n> \n> This program dumps (parts of) a git repository in the format that\n> fast-import understands.\n> \n> For clarity's sake, it does not use the 'inline' method of specifying\n> blobs in the commits, but builds the blobs before building the commits.B\n> \n> ---\n> \tI am way too tired now to continue, but maybe someone else wants\n> \tto pick up the ball.\n> \n> \tOh, and it relies on \"int\" being castable to void * and vice \n> \tversa. Is anybody aware of a platform where this can lead to\n> \tproblems?\n> \n> \tAnd yes, I will add a copyright when I woke up again.\n\nThis one seems to setup a dump of a single branch from the command\nline, which then follows the commit structure. Am I missing\nsomething?\n\nThe cool thing about git-fast-import is that it reads from stdin, has\na very easy to use programmatic interface, and does not impose any\norder on how you enter the information.\n\nThis doesn't seem to be mirrored by this script? \n\nI am working on a script for [company] which uses git. Git is a pain\nto script for: for every query I need to invoke another git process,\nwith another command (log, show-ref, cat-file, show, etc.), parse\nanother output format and/or specify another --pretty=format:%blah\nformat.\n\nBesides being a nuisance, I actually run git on NFS, and every git\nprocess has to go to NFS a couple times to retrieve the same\ninformation. This has a noticeable performance impact.\n\nIt would make my life a lot easier if I could simply open a pipe to a\nsingle process for the duration of the script, and do all my queries\nto this one process. Of course, if the repository is changed by\nanother process, I would have to restart it, but that's manageable. I\ncould even write a nice Python class that runs both fast-import and\nfast-export. I could then have an efficient Python interface to a\ngit-repository, without needing any library wrapping.\n\n--\n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"60728","messageId":"Pine.LNX.4.64.0711230050270.27959@racer.site","threadId":"10948","inReplyTo":"fi5743$32p$1@ger.gmane.org","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-23T01:01:28Z","receivedAt":"2007-11-23T01:01:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[please Cc me when you reply to my message]\n\nOn Thu, 22 Nov 2007, Han-Wen Nienhuys wrote:\n\n> This one seems to setup a dump of a single branch from the command line, \n> which then follows the commit structure. Am I missing something?\n\nYes. It should work with \"--all\", too. In fact, with every rev-list \nparameters, even a..b (which would cut off the history up to -- and \nincluding -- a).\n\n> The cool thing about git-fast-import is that it reads from stdin, has a \n> very easy to use programmatic interface, and does not impose any order \n> on how you enter the information.\n> \n> This doesn't seem to be mirrored by this script? \n\nUmm. What exactly do you want to reorder? I mean, this program is meant \nto dump the complete contents to stdout (whether you redirect it to a file \nor edit it with sed does not concern this program). It does that.\n\nMaybe you want to specify if all blobs should be output first, and then \nthe commits? Or files should be used? But all of these things seem to be \nuseless to me.\n\nSo I am puzzled what you ask for.\n\n> I am working on a script for [company] which uses git. Git is a pain to \n> script for: for every query I need to invoke another git process, with \n> another command (log, show-ref, cat-file, show, etc.), parse another \n> output format and/or specify another --pretty=format:%blah format.\n\nNow I am really puzzled. Git is one of the most easily scriptable \nprograms I ever saw.\n\nIt does not even force you to use certain combinations of scripting \nlanguages, such as Python, Scheme, C++ and PostScript, separated by which \npart of the program you want to script.\n\n> Besides being a nuisance, I actually run git on NFS, and every git \n> process has to go to NFS a couple times to retrieve the same \n> information. This has a noticeable performance impact.\n\nWhy don't you just work on a local clone? If it is really performance \ncritical, and I/O is an issue, you are better off working in a tmpfs.\n\nOnce you're done, you push back to the NFS repository (which is \nlock-challenged AFAIR, but I guess you know that).\n\n> It would make my life a lot easier if I could simply open a pipe to a \n> single process for the duration of the script, and do all my queries to \n> this one process. Of course, if the repository is changed by another \n> process, I would have to restart it, but that's manageable. I could \n> even write a nice Python class that runs both fast-import and \n> fast-export. I could then have an efficient Python interface to a \n> git-repository, without needing any library wrapping.\n\nThere is a minimal python wrapper to libgit-thin, which was one of our \nGSoC projects. You might want to look at this if you are really that \nunhappy with the existing framework.\n\nAs to the niceness of Python classes; this lies definitely in the eyes of \nthe beholder. For example, I have given up on understanding any part of \nyour GUB framework.\n\nCiao,\nDscho\n"},{"id":"60730","messageId":"f329bf540711221723g2754ce03r4da6d429c45668c@mail.gmail.com","threadId":"10948","inReplyTo":"Pine.LNX.4.64.0711230050270.27959@racer.site","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Han-Wen Nienhuys","fromEmail":"hanwenn@gmail.com","sentAt":"2007-11-23T01:23:37Z","receivedAt":"2007-11-23T01:23:37Z","isPatch":true,"sender":{"key":"hanwenn@gmail.com","avatar":"https://gravatar.com/avatar/058832acb8d613baeb6ce9d21b009d9772424a309b9a521330423daef909a27a?d=mp&s=160"},"body":"2007/11/22, Johannes Schindelin :\n> > The cool thing about git-fast-import is that it reads from stdin, has a\n> > very easy to use programmatic interface, and does not impose any order\n> > on how you enter the information.\n> >\n> > This doesn't seem to be mirrored by this script?\n>\n> Umm. What exactly do you want to reorder? I mean, this program is meant\n> to dump the complete contents to stdout (whether you redirect it to a file\n> or edit it with sed does not concern this program). It does that.\n\nfast-import does not need to take a complete repository as input, but\ncan also update lots of branches incrementally, all from one process.\nLikewise, it would be nice to have a program that can also dump small\nbits of information.\n\nMaybe I'm misunderstanding you, but fast-export just does not seem a\nmirror of fast-import; perhaps you can name it 'dump-all' or\nsomething?\n\n> Maybe you want to specify if all blobs should be output first, and then\n> the commits? Or files should be used? But all of these things seem to be\n> useless to me.\n\nNo, I want the program to wait for me to tell it what\nblobs/commits/trees I want. The commit I want to see secondly may\ndepend on the output I read in the first request blob. Right now, for\neach data dependency I have to start a new git process.\n\n> > Besides being a nuisance, I actually run git on NFS, and every git\n> > process has to go to NFS a couple times to retrieve the same\n> > information. This has a noticeable performance impact.\n>\n> Why don't you just work on a local clone? If it is really performance\n> critical, and I/O is an issue, you are better off working in a tmpfs.\n\nIn a company setting, NFS is the easiest way to share information with\ncolleagues without breaking access control and making our security\nstaff nervous. It's also snapshotted and backed up automatically.\n\n> > It would make my life a lot easier if I could simply open a pipe to a\n> > single process for the duration of the script, and do all my queries to\n> > this one process. Of course, if the repository is changed by another\n> > process, I would have to restart it, but that's manageable. I could\n> > even write a nice Python class that runs both fast-import and\n> > fast-export. I could then have an efficient Python interface to a\n> > git-repository, without needing any library wrapping.\n>\n> There is a minimal python wrapper to libgit-thin, which was one of our\n> GSoC projects. You might want to look at this if you are really that\n> unhappy with the existing framework.\n\nWhat's the status of this? I prefer not to diverge from mainline too much.\n\n-- \nHan-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"60732","messageId":"Pine.LNX.4.64.0711230149430.27959@racer.site","threadId":"10948","inReplyTo":"f329bf540711221723g2754ce03r4da6d429c45668c@mail.gmail.com","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-23T02:11:05Z","receivedAt":"2007-11-23T02:11:05Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Nov 2007, Han-Wen Nienhuys wrote:\n\n> Maybe I'm misunderstanding you, but fast-export just does not seem a \n> mirror of fast-import; perhaps you can name it 'dump-all' or something?\n\nIt is a mirror. It does not necessarily dump all.\n\n> > Maybe you want to specify if all blobs should be output first, and \n> > then the commits? Or files should be used? But all of these things \n> > seem to be useless to me.\n> \n> No, I want the program to wait for me to tell it what \n> blobs/commits/trees I want. The commit I want to see secondly may depend \n> on the output I read in the first request blob. Right now, for each data \n> dependency I have to start a new git process.\n\nIt does not seem like you want a mirror of fast-import, but rather a \ndriver. You might be happy to hear that you can do that already. Today.\nHowever, you probably want to query different programs about certain \nstates of the repository. This will not change.\n\n> > > Besides being a nuisance, I actually run git on NFS, and every git \n> > > process has to go to NFS a couple times to retrieve the same \n> > > information. This has a noticeable performance impact.\n> >\n> > Why don't you just work on a local clone? If it is really performance \n> > critical, and I/O is an issue, you are better off working in a tmpfs.\n> \n> In a company setting, NFS is the easiest way to share information with \n> colleagues without breaking access control and making our security staff \n> nervous. It's also snapshotted and backed up automatically.\n\nSo?\n\nHow does that prevent you from following my suggestion to do the intensive \ntasks locally, and push when you finished?\n\nCiao,\nDscho\n"},{"id":"60759","messageId":"fcaeb9bf0711230431x1b0432f6uc9472b2f67514463@mail.gmail.com","threadId":"10948","inReplyTo":"Pine.LNX.4.64.0711210336210.27959@racer.site","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-11-23T12:31:19Z","receivedAt":"2007-11-23T12:31:19Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Nov 21, 2007 10:40 AM, Johannes Schindelin\n wrote:\n>\n> [WIP: this does not handle tags yet, and it lacks a test script\n> as well as documentation.]\n>\n> This program dumps (parts of) a git repository in the format that\n> fast-import understands.\n>\n> For clarity's sake, it does not use the 'inline' method of specifying\n> blobs in the commits, but builds the blobs before building the commits.B\n>\n> ---\n> I am way too tired now to continue, but maybe someone else wants\n> to pick up the ball.\n\nWell, I would better be back on setup_git_directory() than picking up\nthe ball. I have a suggestion though. git-fast-export and\ngit-fast-import should support bundle. Bundle is very handy for\ntransferring a bunch of commits, but it does not (cannot?) hold tags\nand branches. With git-fast-{im,ex}port, we will have a perfect\ntransportation for disconnected development.\n\n> Oh, and it relies on \"int\" being castable to void * and vice\n> versa. Is anybody aware of a platform where this can lead to\n> problems?\n>\n> And yes, I will add a copyright when I woke up again.\n-- \nDuy\n"},{"id":"60763","messageId":"Pine.LNX.4.64.0711231428350.27959@racer.site","threadId":"10948","inReplyTo":"fcaeb9bf0711230431x1b0432f6uc9472b2f67514463@mail.gmail.com","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-23T14:31:18Z","receivedAt":"2007-11-23T14:31:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Nov 2007, Nguyen Thai Ngoc Duy wrote:\n\n> On Nov 21, 2007 10:40 AM, Johannes Schindelin\n> wrote:\n> >\n> > [WIP: this does not handle tags yet, and it lacks a test script\n> > as well as documentation.]\n> >\n> > This program dumps (parts of) a git repository in the format that\n> > fast-import understands.\n> >\n> > For clarity's sake, it does not use the 'inline' method of specifying\n> > blobs in the commits, but builds the blobs before building the commits.B\n> >\n> > ---\n> > I am way too tired now to continue, but maybe someone else wants\n> > to pick up the ball.\n> \n> Well, I would better be back on setup_git_directory() than picking up\n> the ball.\n\nConcur.\n\n> I have a suggestion though. git-fast-export and git-fast-import should \n> support bundle.\n\nI think this is not what fast-export and fast-import are about. They use \nan easy to generate, and easy to edit, format.\n\nBundles are optimised transport mechanisms for sneaker net. They are not \nto be meant to be easy to edit, but as small as possible.\n\n> Bundle is very handy for transferring a bunch of commits, but it does \n> not (cannot?) hold tags and branches.\n\nBut they can! Nothing prevents you from calling\n\n\tgit bundle create a1.bundle refs/tags/v1.0.0 refs/heads/next\n\n(At least this is the idea, haven't tested yet).\n\nCiao,\nDscho\n"},{"id":"60788","messageId":"20071123205652.GA14735@spearce.org","threadId":"10948","inReplyTo":"Pine.LNX.4.64.0711231428350.27959@racer.site","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-11-23T20:56:52Z","receivedAt":"2007-11-23T20:56:52Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Fri, 23 Nov 2007, Nguyen Thai Ngoc Duy wrote:\n> > I have a suggestion though. git-fast-export and git-fast-import should \n> > support bundle.\n> \n> I think this is not what fast-export and fast-import are about. They use \n> an easy to generate, and easy to edit, format.\n> \n> Bundles are optimised transport mechanisms for sneaker net. They are not \n> to be meant to be easy to edit, but as small as possible.\n\nActually I wonder, what about bundles that are formatted as a\ngit-fast-import data stream? Then you can have a human readable\nbundle format that can be (reasonably) easily turned back into a\npackfile and loaded into the local ODB.\n\nOnly we'd probably want to express blobs as diffs if we can, to\nsave disk space, which means we'd need to have git-apply organized\nin a way that we can call it from within fast-import. :-)\n\nBut I agree with Dscho's basic comment; fast-import should not\nbe reading a bundle. It doesn't want to. That's what git-bundle\nis for.\n\n-- \nShawn.\n"},{"id":"60791","messageId":"20071123205958.GC14735@spearce.org","threadId":"10948","inReplyTo":"Pine.LNX.4.64.0711230149430.27959@racer.site","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-11-23T20:59:58Z","receivedAt":"2007-11-23T20:59:58Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Thu, 22 Nov 2007, Han-Wen Nienhuys wrote:\n> \n> > > Maybe you want to specify if all blobs should be output first, and \n> > > then the commits? Or files should be used? But all of these things \n> > > seem to be useless to me.\n> > \n> > No, I want the program to wait for me to tell it what \n> > blobs/commits/trees I want. The commit I want to see secondly may depend \n> > on the output I read in the first request blob. Right now, for each data \n> > dependency I have to start a new git process.\n> \n> It does not seem like you want a mirror of fast-import, but rather a \n> driver. You might be happy to hear that you can do that already. Today.\n> However, you probably want to query different programs about certain \n> states of the repository. This will not change.\n> \n> > > > Besides being a nuisance, I actually run git on NFS, and every git \n> > > > process has to go to NFS a couple times to retrieve the same \n> > > > information. This has a noticeable performance impact.\n\nI have been considering creating a \"git-gui daemon\" process that\nlinks to libgit.a and can be driven bidirectionally through its\nstdin/stdout. Based on git-fast-export, sorta. But I haven't\neven started it...\n\nBut the idea is sort of what Han-Wen wants. Why should I fork\nrev-parse to get a ref value? Or update-ref to change one?\n\n-- \nShawn.\n"},{"id":"60814","messageId":"fcaeb9bf0711240608w2e5e0812me0e56c1f1a2f8c85@mail.gmail.com","threadId":"10948","inReplyTo":"Pine.LNX.4.64.0711231428350.27959@racer.site","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-11-24T14:08:46Z","receivedAt":"2007-11-24T14:08:46Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Nov 23, 2007 9:31 PM, Johannes Schindelin wrote:\n> Hi,\n>\n> On Fri, 23 Nov 2007, Nguyen Thai Ngoc Duy wrote:\n>\n> > On Nov 21, 2007 10:40 AM, Johannes Schindelin\n> > wrote:\n> > >\n> > > [WIP: this does not handle tags yet, and it lacks a test script\n> > > as well as documentation.]\n> > >\n> > > This program dumps (parts of) a git repository in the format that\n> > > fast-import understands.\n> > >\n> > > For clarity's sake, it does not use the 'inline' method of specifying\n> > > blobs in the commits, but builds the blobs before building the commits.B\n> > >\n> > > ---\n> > > I am way too tired now to continue, but maybe someone else wants\n> > > to pick up the ball.\n> >\n> > Well, I would better be back on setup_git_directory() than picking up\n> > the ball.\n>\n> Concur.\n>\n> > I have a suggestion though. git-fast-export and git-fast-import should\n> > support bundle.\n>\n> I think this is not what fast-export and fast-import are about. They use\n> an easy to generate, and easy to edit, format.\n>\n> Bundles are optimised transport mechanisms for sneaker net. They are not\n> to be meant to be easy to edit, but as small as possible.\n>\n> > Bundle is very handy for transferring a bunch of commits, but it does\n> > not (cannot?) hold tags and branches.\n>\n> But they can! Nothing prevents you from calling\n>\n> git bundle create a1.bundle refs/tags/v1.0.0 refs/heads/next\n>\n> (At least this is the idea, haven't tested yet).\n\nIt can store commits and heavy tags, but it won't restore tags to\nrefs/tags or advance branches.\n\n-- \nDuy\n"},{"id":"60836","messageId":"20071125170019.GB25800@diana.vm.bytemark.co.uk","threadId":"10948","inReplyTo":"20071123205958.GC14735@spearce.org","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-25T17:00:19Z","receivedAt":"2007-11-25T17:00:19Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-23 15:59:58 -0500, Shawn O. Pearce wrote:\n\n> I have been considering creating a \"git-gui daemon\" process that\n> links to libgit.a and can be driven bidirectionally through its\n> stdin/stdout. Based on git-fast-export, sorta. But I haven't even\n> started it...\n>\n> But the idea is sort of what Han-Wen wants. Why should I fork\n> rev-parse to get a ref value? Or update-ref to change one?\n\nObviously, something like this would be very valuable for StGit as\nwell.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"60943","messageId":"Pine.LNX.4.64.0711261646170.27959@racer.site","threadId":"10948","inReplyTo":"20071123205958.GC14735@spearce.org","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-26T16:47:30Z","receivedAt":"2007-11-26T16:47:30Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Nov 2007, Shawn O. Pearce wrote:\n\n> Johannes Schindelin wrote:\n> > On Thu, 22 Nov 2007, Han-Wen Nienhuys wrote:\n> > \n> > > > Maybe you want to specify if all blobs should be output first, and \n> > > > then the commits? Or files should be used? But all of these things \n> > > > seem to be useless to me.\n> > > \n> > > No, I want the program to wait for me to tell it what \n> > > blobs/commits/trees I want. The commit I want to see secondly may depend \n> > > on the output I read in the first request blob. Right now, for each data \n> > > dependency I have to start a new git process.\n> > \n> > It does not seem like you want a mirror of fast-import, but rather a \n> > driver. You might be happy to hear that you can do that already. Today.\n> > However, you probably want to query different programs about certain \n> > states of the repository. This will not change.\n> > \n> > > > > Besides being a nuisance, I actually run git on NFS, and every git \n> > > > > process has to go to NFS a couple times to retrieve the same \n> > > > > information. This has a noticeable performance impact.\n> \n> I have been considering creating a \"git-gui daemon\" process that links \n> to libgit.a and can be driven bidirectionally through its stdin/stdout. \n> Based on git-fast-export, sorta. But I haven't even started it...\n> \n> But the idea is sort of what Han-Wen wants. Why should I fork rev-parse \n> to get a ref value? Or update-ref to change one?\n\nI was thinking about this a little bit more. But I cannot think of a \nreally versatile way of enhancing fast-export enough to be of use there. \nWell, if not doing something with SWIG, that is ;-)\n\nCiao,\nDscho\n"},{"id":"60944","messageId":"Pine.LNX.4.64.0711261647400.27959@racer.site","threadId":"10948","inReplyTo":"20071125170019.GB25800@diana.vm.bytemark.co.uk","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-26T16:48:14Z","receivedAt":"2007-11-26T16:48:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 25 Nov 2007, Karl Hasselstr?m wrote:\n\n> On 2007-11-23 15:59:58 -0500, Shawn O. Pearce wrote:\n> \n> > I have been considering creating a \"git-gui daemon\" process that links \n> > to libgit.a and can be driven bidirectionally through its \n> > stdin/stdout. Based on git-fast-export, sorta. But I haven't even \n> > started it...\n> >\n> > But the idea is sort of what Han-Wen wants. Why should I fork \n> > rev-parse to get a ref value? Or update-ref to change one?\n> \n> Obviously, something like this would be very valuable for StGit as well.\n\nCould you be a little more specific _what_ you want to do, and _how_ this \ncould be done with fast-export | fast-import?\n\nCiao,\nDscho\n"},{"id":"61042","messageId":"20071127101614.GB26072@diana.vm.bytemark.co.uk","threadId":"10948","inReplyTo":"Pine.LNX.4.64.0711261647400.27959@racer.site","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-27T10:16:14Z","receivedAt":"2007-11-27T10:16:14Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-26 16:48:14 +0000, Johannes Schindelin wrote:\n\n> On Sun, 25 Nov 2007, Karl Hasselström wrote:\n>\n> > On 2007-11-23 15:59:58 -0500, Shawn O. Pearce wrote:\n> >\n> > > I have been considering creating a \"git-gui daemon\" process that\n> > > links to libgit.a and can be driven bidirectionally through its\n> > > stdin/stdout. Based on git-fast-export, sorta. But I haven't\n> > > even started it...\n> > >\n> > > But the idea is sort of what Han-Wen wants. Why should I fork\n> > > rev-parse to get a ref value? Or update-ref to change one?\n> >\n> > Obviously, something like this would be very valuable for StGit as\n> > well.\n>\n> Could you be a little more specific _what_ you want to do, and _how_\n> this could be done with fast-export | fast-import?\n\nCurrently, a single StGit command can result in quite a few\ninvocations of git-cat-file, for example, each of which forks off a\nnew process. If it could start just one daemon such as Shawn proposed,\nand feed it simple questions and commands about blobs, trees, commits,\nand refs, that would probably be quite a lot faster.\n\nFrom what I understand, this is not something that would fit a\nfast-export | fast-import pipeline. Which is why I didn't take the\ntime to elaborate on (or indeed find out) exactly which commands StGit\nwould like such a daemon to support.\n\nBy the way: one command one _would_ likely want in the daemon is \"list\nmodified files\". Being long-lived (not when driven by StGit, perhaps,\nbut definitely when driven by git-gui or qgit), the daemon would be\nable to use inotify for that.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"61051","messageId":"Pine.LNX.4.64.0711271123360.27959@racer.site","threadId":"10948","inReplyTo":"20071127101614.GB26072@diana.vm.bytemark.co.uk","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-27T11:25:47Z","receivedAt":"2007-11-27T11:25:47Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Nov 2007, Karl Hasselstr?m wrote:\n\n> On 2007-11-26 16:48:14 +0000, Johannes Schindelin wrote:\n> \n> > On Sun, 25 Nov 2007, Karl Hasselstr?m wrote:\n> >\n> > > On 2007-11-23 15:59:58 -0500, Shawn O. Pearce wrote:\n> > >\n> > > > I have been considering creating a \"git-gui daemon\" process that \n> > > > links to libgit.a and can be driven bidirectionally through its \n> > > > stdin/stdout. Based on git-fast-export, sorta. But I haven't even \n> > > > started it...\n> > > >\n> > > > But the idea is sort of what Han-Wen wants. Why should I fork \n> > > > rev-parse to get a ref value? Or update-ref to change one?\n> > >\n> > > Obviously, something like this would be very valuable for StGit as \n> > > well.\n> >\n> > Could you be a little more specific _what_ you want to do, and _how_ \n> > this could be done with fast-export | fast-import?\n> \n> Currently, a single StGit command can result in quite a few invocations \n> of git-cat-file, for example, each of which forks off a new process. If \n> it could start just one daemon such as Shawn proposed, and feed it \n> simple questions and commands about blobs, trees, commits, and refs, \n> that would probably be quite a lot faster.\n> \n> From what I understand, this is not something that would fit a \n> fast-export | fast-import pipeline. Which is why I didn't take the time \n> to elaborate on (or indeed find out) exactly which commands StGit would \n> like such a daemon to support.\n> \n> By the way: one command one _would_ likely want in the daemon is \"list \n> modified files\". Being long-lived (not when driven by StGit, perhaps, \n> but definitely when driven by git-gui or qgit), the daemon would be able \n> to use inotify for that.\n\nAh, so you would like something like \"git --interactive\"? This is indeed \na completely different scope than the fast-export thingie, which is meant \nas kind of a mysqldump tool. Indeed, you could use it even as a (kind of \na) stash of the repo instead of the working tree.\n\nCiao,\nDscho\n"},{"id":"61060","messageId":"Pine.LNX.4.64.0711271214230.27959@racer.site","threadId":"10948","inReplyTo":"fcaeb9bf0711240608w2e5e0812me0e56c1f1a2f8c85@mail.gmail.com","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-27T12:16:47Z","receivedAt":"2007-11-27T12:16:47Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 24 Nov 2007, Nguyen Thai Ngoc Duy wrote:\n\n> On Nov 23, 2007 9:31 PM, Johannes Schindelin wrote:\n>\n> > On Fri, 23 Nov 2007, Nguyen Thai Ngoc Duy wrote:\n> >\n> > > Bundle is very handy for transferring a bunch of commits, but it \n> > > does not (cannot?) hold tags and branches.\n> >\n> > But they can! Nothing prevents you from calling\n> >\n> > git bundle create a1.bundle refs/tags/v1.0.0 refs/heads/next\n> >\n> > (At least this is the idea, haven't tested yet).\n> \n> It can store commits and heavy tags, but it won't restore tags to \n> refs/tags or advance branches.\n\nThe idea is that you fetch them from the bundle. So something like this \nshould do what you want:\n\n\tgit fetch a1.bundle v1.0.0:refs/tags/v1.0.0\n\nNote that the automatic tag handling of git fetch kicks in with bundles \njust like with other fetch URLs (Unassuming Repository Locators).\n\nCiao,\nDscho\n"},{"id":"61076","messageId":"fcaeb9bf0711270617u5ccba66dx6278e322e8c376@mail.gmail.com","threadId":"10948","inReplyTo":"Pine.LNX.4.64.0711271214230.27959@racer.site","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-11-27T14:17:10Z","receivedAt":"2007-11-27T14:17:10Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Nov 27, 2007 7:16 PM, Johannes Schindelin wrote:\n> Hi,\n>\n> On Sat, 24 Nov 2007, Nguyen Thai Ngoc Duy wrote:\n>\n> > On Nov 23, 2007 9:31 PM, Johannes Schindelin wrote:\n> >\n> > > On Fri, 23 Nov 2007, Nguyen Thai Ngoc Duy wrote:\n> > >\n> > > > Bundle is very handy for transferring a bunch of commits, but it\n> > > > does not (cannot?) hold tags and branches.\n> > >\n> > > But they can! Nothing prevents you from calling\n> > >\n> > > git bundle create a1.bundle refs/tags/v1.0.0 refs/heads/next\n> > >\n> > > (At least this is the idea, haven't tested yet).\n> >\n> > It can store commits and heavy tags, but it won't restore tags to\n> > refs/tags or advance branches.\n>\n> The idea is that you fetch them from the bundle. So something like this\n> should do what you want:\n>\n> git fetch a1.bundle v1.0.0:refs/tags/v1.0.0\n>\n> Note that the automatic tag handling of git fetch kicks in with bundles\n> just like with other fetch URLs (Unassuming Repository Locators).\n\nYes, you are right. Man, if I knew I could pass a bundle to git-fetch,\nmy life would have been much easier :(\n-- \nDuy\n"},{"id":"61083","messageId":"20071127145103.GA30020@diana.vm.bytemark.co.uk","threadId":"10948","inReplyTo":"Pine.LNX.4.64.0711271123360.27959@racer.site","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-27T14:51:03Z","receivedAt":"2007-11-27T14:51:03Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-27 11:25:47 +0000, Johannes Schindelin wrote:\n\n> Ah, so you would like something like \"git --interactive\"? This is\n> indeed a completely different scope than the fast-export thingie,\n\nYes. Or rather, I _think_ that's what I want. The only numbers I have\nis that StGit makes a number of trivial git calls that right now take\non the order of 10 ms apiece, so the first step in this direction\nwould be to build a simple prototype just to see what kind of speed-up\none could expect (both in the git calls, and in StGit overall).\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"61086","messageId":"Pine.LNX.4.64.0711271510090.27959@racer.site","threadId":"10948","inReplyTo":"20071127145103.GA30020@diana.vm.bytemark.co.uk","subject":"Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-27T15:10:41Z","receivedAt":"2007-11-27T15:10:41Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Nov 2007, Karl Hasselstr?m wrote:\n\n> On 2007-11-27 11:25:47 +0000, Johannes Schindelin wrote:\n> \n> > Ah, so you would like something like \"git --interactive\"? This is \n> > indeed a completely different scope than the fast-export thingie,\n> \n> Yes. Or rather, I _think_ that's what I want. The only numbers I have is \n> that StGit makes a number of trivial git calls that right now take on \n> the order of 10 ms apiece, so the first step in this direction would be \n> to build a simple prototype just to see what kind of speed-up one could \n> expect (both in the git calls, and in StGit overall).\n\nI'd rather see you using libgit-thin's Python binding.\n\nCiao,\nDscho\n"}]}