{"thread":{"id":"13802","subject":"[PATCH] builtin-fast-export: Add importing and exporting of revision marks","startedAt":"2008-06-04T20:55:47Z","lastAt":"2008-06-11T21:43:06Z","messageCount":18,"participants":["Pieter de Bie","Johannes Schindelin","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"78668","messageId":"1212612947-34720-1-git-send-email-pdebie@ai.rug.nl","threadId":"13802","inReplyTo":null,"subject":"[PATCH] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-06-04T20:55:47Z","receivedAt":"2008-06-04T20:55:47Z","isPatch":true,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"This adds the --import-marks and --export-marks to fast-export. These import\nand export the marks used to for all revisions exported in a similar fashion\nto what fast-import does. The format is the same as fast-import, so you can\ncreate a bidirectional importer / exporter by using the same marks file on\nboth sides.\n---\n\nI used this to create a bidirectional import/export script between Git and\nBazaar. As both sides can now both import and export marks, keeping two\nrepositories in sync is just a matter of keeping the marks files up to date.\n\nThis is my first c code that's more than one line, so please don't be too\nharsh ;)\n\n builtin-fast-export.c |   71 +++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 71 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-fast-export.c b/builtin-fast-export.c\nindex 8218199..1d5c83d 100755\n--- a/builtin-fast-export.c\n+++ b/builtin-fast-export.c\n@@ -375,30 +375,98 @@ static void handle_tags_and_duplicates(struct path_list *extra_refs)\n \t}\n }\n \n+static void export_marks(char * file)\n+{\n+\tunsigned int i;\n+\tuintmax_t mark;\n+\tstruct object_decoration *deco = idnums.hash;\n+\tFILE *f;\n+\n+\tf = fopen(file, \"w\");\n+\tif (!f)\n+\t\terror(\"Unable to open marks file %s for writing\", file);\n+\n+\tfor (i = 0; i < idnums.size; ++i) {\n+\t\tdeco++;\n+\t\tif (deco && deco->base && deco->base->type == 1) {\n+\t\t\tmark = (uint32_t *) deco-> decoration - (uint32_t *)NULL;\n+\t\t\tfprintf(f, \":%\" PRIuMAX \" %s\\n\", mark, sha1_to_hex(deco->base->sha1));\n+\t\t}\n+\t}\n+\tif (ferror(f) || fclose(f)) {\n+\t\terror(\"Unable to write marks file %s.\", file);\n+\t}\n+}\n+\n+static void import_marks(char * input_file)\n+{\n+\tchar line[512];\n+\tFILE *f = fopen(input_file, \"r\");\n+\tif (!f)\n+\t\tdie(\"cannot read %s: %s\", input_file, strerror(errno));\n+\n+\twhile (fgets(line, sizeof(line), f)) {\n+\t\tuintmax_t mark;\n+\t\tchar *end;\n+\t\tunsigned char sha1[20];\n+\t\tstruct object *object;\n+\n+\t\tend = strchr(line, '\\n');\n+\t\tif (line[0] != ':' || !end)\n+\t\t\tdie(\"corrupt mark line: %s\", line);\n+\t\t*end = 0;\n+\t\tmark = strtoumax(line + 1, &end, 10);\n+\t\tif (!mark || end == line + 1\n+\t\t\t|| *end != ' ' || get_sha1(end + 1, sha1))\n+\t\t\tdie(\"corrupt mark line: %s\", line);\n+\n+\t\tobject = parse_object(sha1);\n+\t\tif (!object)\n+\t\t\tdie (\"Could not read blob %s\", sha1_to_hex(sha1));\n+\n+\t\tif (object->flags & SHOWN)\n+\t\t\terror(\"Object %s was already has a mark\", sha1);\n+\n+\t\tadd_decoration(&idnums, object, ((uint32_t *)NULL) + mark);\n+\t\tif (last_idnum < mark)\n+\t\t\tlast_idnum = mark;\n+\n+\t\tobject->flags |= SHOWN;\n+\t}\n+\tfclose(f);\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+\tchar *export_filename, *import_filename;\n \tstruct option options[] = {\n \t\tOPT_INTEGER(0, \"progress\", &progress,\n \t\t\t    \"show progress after <n> objects\"),\n \t\tOPT_CALLBACK(0, \"signed-tags\", &signed_tag_mode, \"mode\",\n \t\t\t     \"select handling of signed tags\",\n \t\t\t     parse_opt_signed_tag_mode),\n+\t\tOPT_STRING(0, \"export-marks\", &export_filename, \"FILE\", \"Dump marks to this file\"),\n+\t\tOPT_STRING(0, \"import-marks\", &import_filename, \"FILE\", \"Import marks from this file\"),\n \t\tOPT_END()\n \t};\n \n \t/* we handle encodings */\n \tgit_config(git_default_config, NULL);\n \n+\n \tinit_revisions(&revs, prefix);\n \targc = setup_revisions(argc, argv, &revs, NULL);\n \targc = parse_options(argc, argv, options, fast_export_usage, 0);\n \tif (argc > 1)\n \t\tusage_with_options (fast_export_usage, options);\n \n+\tif (import_filename)\n+\t\timport_marks(import_filename);\n+\n \tget_tags_and_duplicates(&revs.pending, &extra_refs);\n \n \tif (prepare_revision_walk(&revs))\n@@ -421,5 +489,8 @@ int cmd_fast_export(int argc, const char **argv, const char *prefix)\n \n \thandle_tags_and_duplicates(&extra_refs);\n \n+\tif (export_filename)\n+\t\texport_marks(export_filename);\n+\n \treturn 0;\n }\n-- \n1.5.6.rc0.165.ge08d6b.dirty\n"},{"id":"78680","messageId":"alpine.DEB.1.00.0806050052390.21190@racer","threadId":"13802","inReplyTo":"1212612947-34720-1-git-send-email-pdebie@ai.rug.nl","subject":"Re: [PATCH] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-05T00:00:32Z","receivedAt":"2008-06-05T00:00:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 4 Jun 2008, Pieter de Bie wrote:\n\n> +static void export_marks(char * file)\n\nExtra space after star.\n\n> +{\n> +\tunsigned int i;\n> +\tuintmax_t mark;\n> +\tstruct object_decoration *deco = idnums.hash;\n> +\tFILE *f;\n> +\n> +\tf = fopen(file, \"w\");\n> +\tif (!f)\n> +\t\terror(\"Unable to open marks file %s for writing\", file);\n> +\n> +\tfor (i = 0; i < idnums.size; ++i) {\n> +\t\tdeco++;\n> +\t\tif (deco && deco->base && deco->base->type == 1) {\n> +\t\t\tmark = (uint32_t *) deco-> decoration - (uint32_t *)NULL;\n\nWhy do you use uint32_t here, when you use uintmax_t to declare \"mark\"?\n\nAlso, there is an extra space after the closing paren.\n\nIs \"- (uint32_t *)NULL\" needed?\n\n> +\t\t\tfprintf(f, \":%\" PRIuMAX \" %s\\n\", mark, sha1_to_hex(deco->base->sha1));\n\nToo long line.\n\nIf you already only use uint32_t, I think you do not need the (ugly) \nPRIuMAX.\n\n> +static void import_marks(char * input_file)\n> +{\n> +\tchar line[512];\n> +\tFILE *f = fopen(input_file, \"r\");\n> +\tif (!f)\n> +\t\tdie(\"cannot read %s: %s\", input_file, strerror(errno));\n> +\n> +\twhile (fgets(line, sizeof(line), f)) {\n> +\t\tuintmax_t mark;\n> +\t\tchar *end;\n> +\t\tunsigned char sha1[20];\n> +\t\tstruct object *object;\n> +\n> +\t\tend = strchr(line, '\\n');\n> +\t\tif (line[0] != ':' || !end)\n> +\t\t\tdie(\"corrupt mark line: %s\", line);\n> +\t\t*end = 0;\n> +\t\tmark = strtoumax(line + 1, &end, 10);\n> +\t\tif (!mark || end == line + 1\n> +\t\t\t|| *end != ' ' || get_sha1(end + 1, sha1))\n> +\t\t\tdie(\"corrupt mark line: %s\", line);\n\nYou do a bit too much with \"end\" for my liking.  Better use two variables, \nand spare the reader a (brief) \"Huh?\" moment.\n\n> +\t\tobject = parse_object(sha1);\n> +\t\tif (!object)\n> +\t\t\tdie (\"Could not read blob %s\", sha1_to_hex(sha1));\n> +\n> +\t\tif (object->flags & SHOWN)\n> +\t\t\terror(\"Object %s was already has a mark\", sha1);\n\ns/was //\n\n> +\t\tadd_decoration(&idnums, object, ((uint32_t *)NULL) + mark);\n\nBetter write (void *)mark.\n\n> +\tchar *export_filename, *import_filename;\n>  \tstruct option options[] = {\n>  \t\tOPT_INTEGER(0, \"progress\", &progress,\n>  \t\t\t    \"show progress after <n> objects\"),\n>  \t\tOPT_CALLBACK(0, \"signed-tags\", &signed_tag_mode, \"mode\",\n>  \t\t\t     \"select handling of signed tags\",\n>  \t\t\t     parse_opt_signed_tag_mode),\n> +\t\tOPT_STRING(0, \"export-marks\", &export_filename, \"FILE\", \"Dump marks to this file\"),\n> +\t\tOPT_STRING(0, \"import-marks\", &import_filename, \"FILE\", \"Import marks from this file\"),\n\nTwo long lines.\n\n>  \t\tOPT_END()\n>  \t};\n>  \n>  \t/* we handle encodings */\n>  \tgit_config(git_default_config, NULL);\n>  \n> +\n>  \tinit_revisions(&revs, prefix);\n\nUnnecessary change.\n\nOther than that: ACK.\n\nThanks,\nDscho\n"},{"id":"78739","messageId":"BEF1F17D-6F0F-4F09-9CC4-B193B8907901@ai.rug.nl","threadId":"13802","inReplyTo":"alpine.DEB.1.00.0806050052390.21190@racer","subject":"Re: [PATCH] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-06-05T10:46:44Z","receivedAt":"2008-06-05T10:46:44Z","isPatch":true,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn 5 jun 2008, at 02:00, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Wed, 4 Jun 2008, Pieter de Bie wrote:\n>\n>> +{\n>> +\tunsigned int i;\n>> +\tuintmax_t mark;\n>> +\tstruct object_decoration *deco = idnums.hash;\n>> +\tFILE *f;\n>> +\n>> +\tf = fopen(file, \"w\");\n>> +\tif (!f)\n>> +\t\terror(\"Unable to open marks file %s for writing\", file);\n>> +\n>> +\tfor (i = 0; i < idnums.size; ++i) {\n>> +\t\tdeco++;\n>> +\t\tif (deco && deco->base && deco->base->type == 1) {\n>> +\t\t\tmark = (uint32_t *) deco-> decoration - (uint32_t *)NULL;\n>\n> Why do you use uint32_t here, when you use uintmax_t to declare  \n> \"mark\"?\n>\n> Also, there is an extra space after the closing paren.\n>\n> Is \"- (uint32_t *)NULL\" needed?\n\nI changed the uintmax_t to to a uint32_t. If I remove the \"- (uint32_t  \n*)NULL\",\nit won't return the same marks. The same is done in get_object_mark().\n\n>> +static void import_marks(char * input_file)\n>> +{\n>> +\tchar line[512];\n>> +\tFILE *f = fopen(input_file, \"r\");\n>> +\tif (!f)\n>> +\t\tdie(\"cannot read %s: %s\", input_file, strerror(errno));\n>> +\n>> +\twhile (fgets(line, sizeof(line), f)) {\n>> +\t\tuintmax_t mark;\n>> +\t\tchar *end;\n>> +\t\tunsigned char sha1[20];\n>> +\t\tstruct object *object;\n>> +\n>> +\t\tend = strchr(line, '\\n');\n>> +\t\tif (line[0] != ':' || !end)\n>> +\t\t\tdie(\"corrupt mark line: %s\", line);\n>> +\t\t*end = 0;\n>> +\t\tmark = strtoumax(line + 1, &end, 10);\n>> +\t\tif (!mark || end == line + 1\n>> +\t\t\t|| *end != ' ' || get_sha1(end + 1, sha1))\n>> +\t\t\tdie(\"corrupt mark line: %s\", line);\n>\n> You do a bit too much with \"end\" for my liking.  Better use two  \n> variables,\n> and spare the reader a (brief) \"Huh?\" moment.\n\nRight. I copied this code from fast-export.c. I changed it to two  \nvariables now.\n\n>> +\t\tadd_decoration(&idnums, object, ((uint32_t *)NULL) + mark);\n>\n> Better write (void *)mark.\n\nThat won't return the same result, as pointer addition goes with 4  \nbytes. The\nsame thing is done in mark_object().\n\nI will send an updated patch.\n\n- Pieter\n"},{"id":"78741","messageId":"1212663163-43064-1-git-send-email-pdebie@ai.rug.nl","threadId":"13802","inReplyTo":"BEF1F17D-6F0F-4F09-9CC4-B193B8907901@ai.rug.nl","subject":"[PATCH v2] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-06-05T10:52:43Z","receivedAt":"2008-06-05T10:52:43Z","isPatch":true,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"This adds the --import-marks and --export-marks to fast-export. These import\nand export the marks used to for all revisions exported in a similar fashion\nto what fast-import does. The format is the same as fast-import, so you can\ncreate a bidirectional importer / exporter by using the same marks file on\nboth sides.\n\nSigned-off-by: Pieter de Bie <pdebie@ai.rug.nl>\n---\n builtin-fast-export.c |   74 +++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 74 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-fast-export.c b/builtin-fast-export.c\nindex 1dfc01e..8aed868 100755\n--- a/builtin-fast-export.c\n+++ b/builtin-fast-export.c\n@@ -352,18 +352,86 @@ static void handle_tags_and_duplicates(struct path_list *extra_refs)\n \t}\n }\n \n+static void export_marks(char *file)\n+{\n+\tunsigned int i;\n+\tuint32_t mark;\n+\tstruct object_decoration *deco = idnums.hash;\n+\tFILE *f;\n+\n+\tf = fopen(file, \"w\");\n+\tif (!f)\n+\t\terror(\"Unable to open marks file %s for writing\", file);\n+\n+\tfor (i = 0; i < idnums.size; ++i) {\n+\t\tdeco++;\n+\t\tif (deco && deco->base && deco->base->type == 1) {\n+\t\t\tmark = (uint32_t *)deco->decoration - (uint32_t *)NULL;\n+\t\t\tfprintf(f, \":%u %s\\n\", mark,\n+\t\t\t\tsha1_to_hex(deco->base->sha1));\n+\t\t}\n+\t}\n+\n+\tif (ferror(f) || fclose(f))\n+\t\terror(\"Unable to write marks file %s.\", file);\n+}\n+\n+static void import_marks(char * input_file)\n+{\n+\tchar line[512];\n+\tFILE *f = fopen(input_file, \"r\");\n+\tif (!f)\n+\t\tdie(\"cannot read %s: %s\", input_file, strerror(errno));\n+\n+\twhile (fgets(line, sizeof(line), f)) {\n+\t\tuint32_t mark;\n+\t\tchar *line_end, *mark_end;\n+\t\tunsigned char sha1[20];\n+\t\tstruct object *object;\n+\n+\t\tline_end = strchr(line, '\\n');\n+\t\tif (line[0] != ':' || !line_end)\n+\t\t\tdie(\"corrupt mark line: %s\", line);\n+\t\t*line_end = 0;\n+\n+\t\tmark = strtoumax(line + 1, &mark_end, 10);\n+\t\tif (!mark || mark_end == line + 1\n+\t\t\t|| *mark_end != ' ' || get_sha1(mark_end + 1, sha1))\n+\t\t\tdie(\"corrupt mark line: %s\", line);\n+\n+\t\tobject = parse_object(sha1);\n+\t\tif (!object)\n+\t\t\tdie (\"Could not read blob %s\", sha1_to_hex(sha1));\n+\n+\t\tif (object->flags & SHOWN)\n+\t\t\terror(\"Object %s already has a mark\", sha1);\n+\n+\t\tadd_decoration(&idnums, object, ((uint32_t *)NULL) + mark);\n+\t\tif (last_idnum < mark)\n+\t\t\tlast_idnum = mark;\n+\n+\t\tobject->flags |= SHOWN;\n+\t}\n+\tfclose(f);\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+\tchar *export_filename, *import_filename;\n \tstruct option options[] = {\n \t\tOPT_INTEGER(0, \"progress\", &progress,\n \t\t\t    \"show progress after <n> objects\"),\n \t\tOPT_CALLBACK(0, \"signed-tags\", &signed_tag_mode, \"mode\",\n \t\t\t     \"select handling of signed tags\",\n \t\t\t     parse_opt_signed_tag_mode),\n+\t\tOPT_STRING(0, \"export-marks\", &export_filename, \"FILE\",\n+\t\t\t   \"Dump marks to this file\"),\n+\t\tOPT_STRING(0, \"import-marks\", &import_filename, \"FILE\",\n+\t\t\t   \"Import marks from this file\"),\n \t\tOPT_END()\n \t};\n \n@@ -376,6 +444,9 @@ int cmd_fast_export(int argc, const char **argv, const char *prefix)\n \tif (argc > 1)\n \t\tusage_with_options (fast_export_usage, options);\n \n+\tif (import_filename)\n+\t\timport_marks(import_filename);\n+\n \tget_tags_and_duplicates(&revs.pending, &extra_refs);\n \n \tif (prepare_revision_walk(&revs))\n@@ -398,5 +469,8 @@ int cmd_fast_export(int argc, const char **argv, const char *prefix)\n \n \thandle_tags_and_duplicates(&extra_refs);\n \n+\tif (export_filename)\n+\t\texport_marks(export_filename);\n+\n \treturn 0;\n }\n-- \n1.5.6.rc0.165.ge08d6b.dirty\n"},{"id":"78769","messageId":"alpine.DEB.1.00.0806051429300.21190@racer","threadId":"13802","inReplyTo":"BEF1F17D-6F0F-4F09-9CC4-B193B8907901@ai.rug.nl","subject":"Re: [PATCH] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-05T13:31:18Z","receivedAt":"2008-06-05T13:31:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 5 Jun 2008, Pieter de Bie wrote:\n\n> On 5 jun 2008, at 02:00, Johannes Schindelin wrote:\n> \n> >Is \"- (uint32_t *)NULL\" needed?\n> \n> I changed the uintmax_t to to a uint32_t. If I remove the \"- (uint32_t\n> *)NULL\", it won't return the same marks. The same is done in \n>  get_object_mark().\n\nAh, I missed that again.  I think I had exactly the same issue (of not \nunderstanding) with another patch for the same area of the code.\n\nMaybe it would be worth having two functions to describe what is done \nthere, for documentation purposes?\n\n> I will send an updated patch.\n\nThanks,\nDscho\n"},{"id":"78771","messageId":"alpine.DEB.1.00.0806051433590.21190@racer","threadId":"13802","inReplyTo":"1212663163-43064-1-git-send-email-pdebie@ai.rug.nl","subject":"Re: [PATCH v2] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-05T13:35:11Z","receivedAt":"2008-06-05T13:35:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 5 Jun 2008, Pieter de Bie wrote:\n\n> This adds the --import-marks and --export-marks to fast-export. These \n> import and export the marks used to for all revisions exported in a \n> similar fashion to what fast-import does. The format is the same as \n> fast-import, so you can create a bidirectional importer / exporter by \n> using the same marks file on both sides.\n\nNicely done.  As I said, I would like the pointer magic to be wrapped in a \nfunction so that this programmer does not get confused by it again, but \nit's not that important.  IOW only do it if you agree strongly.\n\nOther than that, ACK.\n\nCiao,\nDscho\n"},{"id":"78975","messageId":"7v8wxirwi1.fsf@gitster.siamese.dyndns.org","threadId":"13802","inReplyTo":"1212663163-43064-1-git-send-email-pdebie@ai.rug.nl","subject":"Re: [PATCH v2] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-06T23:09:42Z","receivedAt":"2008-06-06T23:09:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pieter de Bie <pdebie@ai.rug.nl> writes:\n\n> +static void export_marks(char *file)\n> +{\n> +\tunsigned int i;\n> +\tuint32_t mark;\n> +\tstruct object_decoration *deco = idnums.hash;\n> +\tFILE *f;\n> +\n> +\tf = fopen(file, \"w\");\n> +\tif (!f)\n> +\t\terror(\"Unable to open marks file %s for writing\", file);\n> +\n> +\tfor (i = 0; i < idnums.size; ++i) {\n> +\t\tdeco++;\n> ...\n> +\t\t\tmark = (uint32_t *)deco->decoration - (uint32_t *)NULL;\n> +\t\t\tfprintf(f, \":%u %s\\n\", mark,\n> +\t\t\t\tsha1_to_hex(deco->base->sha1));\n> ...\n> +}\n> +\n> +static void import_marks(char * input_file)\n> ...\n> +\t\tadd_decoration(&idnums, object, ((uint32_t *)NULL) + mark);\n\nI am confused.\n\nThe type of object_decoration.decorattion is a (void*).  Why isn't it\nsufficient to do it in a naïve and straightforward way?\n\n\tmark = (uint32_t)(deco->decoration);\n        add_decoration(&idnums, object, (void*) mark);\n\nIs this twisted pointer arithmetic done in order to avoid cast between int\nand pointer of different size in the code?  Even if that is the case,\ndoesn't \"(uint32_t *)deco->decoration - (uint32_t *)NULL\" mean the value\nrange for deco->decoration is one-fourth of U32?  What are you gaining\nfrom using \"uint32_t *\" instead of some other pointer types, say \"char *\"?\n"},{"id":"79041","messageId":"DB158BDE-70D1-4779-9B03-A85C60EB2FA7@ai.rug.nl","threadId":"13802","inReplyTo":"7v8wxirwi1.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v2] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-06-07T13:06:01Z","receivedAt":"2008-06-07T13:06:01Z","isPatch":true,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn 7 jun 2008, at 01:09, Junio C Hamano wrote:\n\n> I am confused.\n>\n> The type of object_decoration.decorattion is a (void*).  Why isn't it\n> sufficient to do it in a naïve and straightforward way?\n>\n> \tmark = (uint32_t)(deco->decoration);\n>        add_decoration(&idnums, object, (void*) mark);\n>\n> Is this twisted pointer arithmetic done in order to avoid cast  \n> between int\n> and pointer of different size in the code?\n\nI'm not sure why this is done; I simply copied what the existing code  \nalready\ndid.\n\n>  Even if that is the case,\n> doesn't \"(uint32_t *)deco->decoration - (uint32_t *)NULL\" mean the  \n> value\n> range for deco->decoration is one-fourth of U32?\n\nI'd imagine so, yes\n\n- Pieter\n"},{"id":"79042","messageId":"1212845104-79789-1-git-send-email-pdebie@ai.rug.nl","threadId":"13802","inReplyTo":"1212663163-43064-1-git-send-email-pdebie@ai.rug.nl","subject":"[PATCH] Documentation/fast-export: Document --import-marks and --export-marks options","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-06-07T13:25:04Z","receivedAt":"2008-06-07T13:25:04Z","isPatch":true,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"This adds a description for git-fast-export's --import-marks and\n--export-marks options to its man page.\n---\n\nI forgot to add the options to the man page. Perhaps this should be squashed\non top of the other patch?\n\n Documentation/git-fast-export.txt |   20 ++++++++++++++++++++\n 1 files changed, 20 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt\nindex 332346c..277a547 100644\n--- a/Documentation/git-fast-export.txt\n+++ b/Documentation/git-fast-export.txt\n@@ -36,6 +36,26 @@ when encountering a signed tag.  With 'strip', the tags will be made\n unsigned, with 'verbatim', they will be silently exported\n and with 'warn', they will be exported, but you will see a warning.\n \n+--export-marks=<file>::\n+\tDumps the internal marks table to <file> when complete.\n+\tMarks are written one per line as `:markid SHA-1`. Only marks\n+\tfor revisions are dumped; marks for blobs are ignored.\n+\tBackends can use this file to validate imports after they\n+\thave been completed, or to save the marks table across\n+\tincremental runs.  As <file> is only opened and truncated\n+\tat completion, the same path can also be safely given to\n+\t\\--import-marks.\n+\n+--import-marks=<file>::\n+\tBefore processing any input, load the marks specified in\n+\t<file>.  The input file must exist, must be readable, and\n+\tmust use the same format as produced by \\--export-marks.\n++\n+Any commits that have already been marked will not be exported again.\n+If the backend uses a similar \\--import-marks file, this allows for\n+incremental bidirectional exporting of the repository by keeping the\n+marks the same across runs.\n+\n \n EXAMPLES\n --------\n-- \n1.5.6.rc0.165.ge08d6b.dirty\n"},{"id":"79045","messageId":"alpine.DEB.1.00.0806071612460.1783@racer","threadId":"13802","inReplyTo":"DB158BDE-70D1-4779-9B03-A85C60EB2FA7@ai.rug.nl","subject":"Re: [PATCH v2] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-07T15:19:35Z","receivedAt":"2008-06-07T15:19:35Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 7 Jun 2008, Pieter de Bie wrote:\n\n> On 7 jun 2008, at 01:09, Junio C Hamano wrote:\n> \n> >I am confused.\n> >\n> >The type of object_decoration.decorattion is a (void*).  Why isn't it\n> >sufficient to do it in a naïve and straightforward way?\n> >\n> > mark = (uint32_t)(deco->decoration);\n> >       add_decoration(&idnums, object, (void*) mark);\n> >\n> >Is this twisted pointer arithmetic done in order to avoid cast between \n> >int and pointer of different size in the code?\n\nYes, it was done in response to a remark that pointers might not be \nallowed to be unaligned.\n\n> I'm not sure why this is done; I simply copied what the existing code \n> already did.\n\nOkay, I looked again, and indeed, you _copied_ it.  Instead of using the \nfunctions mark_object() and get_object_mark() which are there only to be \nused by you.\n\nSo please fix.\n\n> >Even if that is the case, doesn't \"(uint32_t *)deco->decoration - \n> >(uint32_t *)NULL\" mean the value range for deco->decoration is \n> >one-fourth of U32?\n\nIt is.  But since every object needs already at least 20 bytes, and we do \nnot even have the complete address space to put objects into, and we do \nnot plan to support 64-bit only repositories, I think we are fine.  At \nleast for the moment.\n\nCiao,\nDscho"},{"id":"79046","messageId":"alpine.DEB.1.00.0806071619580.1783@racer","threadId":"13802","inReplyTo":"1212845104-79789-1-git-send-email-pdebie@ai.rug.nl","subject":"Re: [PATCH] Documentation/fast-export: Document --import-marks and --export-marks options","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-07T15:20:29Z","receivedAt":"2008-06-07T15:20:29Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 7 Jun 2008, Pieter de Bie wrote:\n\n> This adds a description for git-fast-export's --import-marks and\n> --export-marks options to its man page.\n> ---\n> \n> I forgot to add the options to the man page. Perhaps this should be \n> squashed on top of the other patch?\n\nYes, that and the patch to use the existing functions to set/get the \nmarks instead of duplicating code.\n\nCiao,\nDscho\n"},{"id":"79056","messageId":"7vy75hnqu7.fsf@gitster.siamese.dyndns.org","threadId":"13802","inReplyTo":"alpine.DEB.1.00.0806071612460.1783@racer","subject":"Re: [PATCH v2] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-07T16:37:52Z","receivedAt":"2008-06-07T16:37:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Okay, I looked again, and indeed, you _copied_ it.  Instead of using the \n> functions mark_object() and get_object_mark() which are there only to be \n> used by you.\n>\n> So please fix.\n>\n>> >Even if that is the case, doesn't \"(uint32_t *)deco->decoration - \n>> >(uint32_t *)NULL\" mean the value range for deco->decoration is \n>> >one-fourth of U32?\n>\n> It is.  But since every object needs already at least 20 bytes, and we do \n> not even have the complete address space to put objects into, and we do \n> not plan to support 64-bit only repositories, I think we are fine.\n\nOh, I was not complaining about the one-fourthness.  I was wondering why\n\"(uint32_t *)\", which makes it look like the type itself has very deep\nmeaning for this computation, was used, instead of \"(char *)\" or something\nthat makes it much clearer that what could be pointed at by the pointer\ndoes not matter and you are only using them as fake integers.  If there is\nsuch a deep meaning, it needs documented, and if there isn't then probably\nthe use of (uint32_t *) should also be fixed.\n"},{"id":"79319","messageId":"7vve0hdbvv.fsf@gitster.siamese.dyndns.org","threadId":"13802","inReplyTo":"1212845104-79789-1-git-send-email-pdebie@ai.rug.nl","subject":"Re: [PATCH] Documentation/fast-export: Document --import-marks and --export-marks options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-10T06:47:48Z","receivedAt":"2008-06-10T06:47:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pieter de Bie <pdebie@ai.rug.nl> writes:\n\n> This adds a description for git-fast-export's --import-marks and\n> --export-marks options to its man page.\n> ---\n>\n> I forgot to add the options to the man page. Perhaps this should be squashed\n> on top of the other patch?\n\nSign-off and tests are missing.\n"},{"id":"79443","messageId":"1213183024-60013-1-git-send-email-pdebie@ai.rug.nl","threadId":"13802","inReplyTo":"7vve0hdbvv.fsf@gitster.siamese.dyndns.org","subject":"[PATCH v3] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-06-11T11:17:04Z","receivedAt":"2008-06-11T11:17:04Z","isPatch":true,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"This adds the --import-marks and --export-marks to fast-export. These import\nand export the marks used to for all revisions exported in a similar fashion\nto what fast-import does. The format is the same as fast-import, so you can\ncreate a bidirectional importer / exporter by using the same marks file on\nboth sides.\n\nSigned-off-by: Pieter de Bie <pdebie@ai.rug.nl>\n---\n\nOn 10 jun 2008, at 08:47, Junio C Hamano wrote:\n>Sign-off and tests are missing.\n  \n  I actually had this new patch ready, but I was hoping Dscho would answer\n  this first:\n  \nOn 7 jun 2008, at 18:37, Junio C Hamano wrote:\n>Oh, I was not complaining about the one-fourthness.  I was wondering why\n>\"(uint32_t *)\", which makes it look like the type itself has very deep\n>meaning for this computation, was used, instead of \"(char *)\" or something\n>that makes it much clearer that what could be pointed at by the pointer\n>does not matter and you are only using them as fake integers.  If there is\n>such a deep meaning, it needs documented, and if there isn't then probably\n>the use of (uint32_t *) should also be fixed.\n  \n  since I don't know the answer to that :)\n  \nOn 7 jun 2008, at 17:19, Johannes Schindelin wrote:\n>Okay, I looked again, and indeed, you _copied_ it.  Instead of using the \n>functions mark_object() and get_object_mark() which are there only to be \n>used by you.\n>\n>So please fix.\n  \n  How about this, explicit enough?\n  \n Documentation/git-fast-export.txt |   20 +++++++\n builtin-fast-export.c             |   99 ++++++++++++++++++++++++++++++++++--\n t/t9301-fast-export.sh            |   24 +++++++++\n 3 files changed, 137 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt\nindex 332346c..277a547 100644\n--- a/Documentation/git-fast-export.txt\n+++ b/Documentation/git-fast-export.txt\n@@ -36,6 +36,26 @@ when encountering a signed tag.  With 'strip', the tags will be made\n unsigned, with 'verbatim', they will be silently exported\n and with 'warn', they will be exported, but you will see a warning.\n \n+--export-marks=<file>::\n+\tDumps the internal marks table to <file> when complete.\n+\tMarks are written one per line as `:markid SHA-1`. Only marks\n+\tfor revisions are dumped; marks for blobs are ignored.\n+\tBackends can use this file to validate imports after they\n+\thave been completed, or to save the marks table across\n+\tincremental runs.  As <file> is only opened and truncated\n+\tat completion, the same path can also be safely given to\n+\t\\--import-marks.\n+\n+--import-marks=<file>::\n+\tBefore processing any input, load the marks specified in\n+\t<file>.  The input file must exist, must be readable, and\n+\tmust use the same format as produced by \\--export-marks.\n++\n+Any commits that have already been marked will not be exported again.\n+If the backend uses a similar \\--import-marks file, this allows for\n+incremental bidirectional exporting of the repository by keeping the\n+marks the same across runs.\n+\n \n EXAMPLES\n --------\ndiff --git a/builtin-fast-export.c b/builtin-fast-export.c\nindex 1dfc01e..94123c3 100755\n--- a/builtin-fast-export.c\n+++ b/builtin-fast-export.c\n@@ -56,10 +56,24 @@ static int has_unshown_parent(struct commit *commit)\n }\n \n /* Since intptr_t is C99, we do not use it here */\n-static void mark_object(struct object *object)\n+static inline uint32_t *mark_to_ptr(uint32_t mark)\n {\n-\tlast_idnum++;\n-\tadd_decoration(&idnums, object, ((uint32_t *)NULL) + last_idnum);\n+\treturn ((uint32_t *)NULL) + mark;\n+}\n+\n+static inline uint32_t ptr_to_mark(void * mark)\n+{\n+\treturn (uint32_t *)mark - (uint32_t *)NULL;\n+}\n+\n+static inline void mark_object(struct object *object, uint32_t mark)\n+{\n+\tadd_decoration(&idnums, object, mark_to_ptr(mark));\n+}\n+\n+static inline void mark_next_object(struct object *object)\n+{\n+\tmark_object(object, ++last_idnum);\n }\n \n static int get_object_mark(struct object *object)\n@@ -67,7 +81,7 @@ static int get_object_mark(struct object *object)\n \tvoid *decoration = lookup_decoration(&idnums, object);\n \tif (!decoration)\n \t\treturn 0;\n-\treturn (uint32_t *)decoration - (uint32_t *)NULL;\n+\treturn ptr_to_mark(decoration);\n }\n \n static void show_progress(void)\n@@ -100,7 +114,7 @@ static void handle_object(const unsigned char *sha1)\n \tif (!buf)\n \t\tdie (\"Could not read blob %s\", sha1_to_hex(sha1));\n \n-\tmark_object(object);\n+\tmark_next_object(object);\n \n \tprintf(\"blob\\nmark :%d\\ndata %lu\\n\", last_idnum, size);\n \tif (size && fwrite(buf, size, 1, stdout) != 1)\n@@ -185,7 +199,7 @@ static void handle_commit(struct commit *commit, struct rev_info *rev)\n \tfor (i = 0; i < diff_queued_diff.nr; i++)\n \t\thandle_object(diff_queued_diff.queue[i]->two->sha1);\n \n-\tmark_object(&commit->object);\n+\tmark_next_object(&commit->object);\n \tif (!is_encoding_utf8(encoding))\n \t\treencoded = reencode_string(message, \"UTF-8\", encoding);\n \tprintf(\"commit %s\\nmark :%d\\n%.*s\\n%.*s\\ndata %u\\n%s\",\n@@ -352,18 +366,85 @@ static void handle_tags_and_duplicates(struct path_list *extra_refs)\n \t}\n }\n \n+static void export_marks(char *file)\n+{\n+\tunsigned int i;\n+\tuint32_t mark;\n+\tstruct object_decoration *deco = idnums.hash;\n+\tFILE *f;\n+\n+\tf = fopen(file, \"w\");\n+\tif (!f)\n+\t\terror(\"Unable to open marks file %s for writing\", file);\n+\n+\tfor (i = 0; i < idnums.size; ++i) {\n+\t\tdeco++;\n+\t\tif (deco && deco->base && deco->base->type == 1) {\n+\t\t\tmark = ptr_to_mark(deco->decoration);\n+\t\t\tfprintf(f, \":%u %s\\n\", mark, sha1_to_hex(deco->base->sha1));\n+\t\t}\n+\t}\n+\n+\tif (ferror(f) || fclose(f))\n+\t\terror(\"Unable to write marks file %s.\", file);\n+}\n+\n+static void import_marks(char * input_file)\n+{\n+\tchar line[512];\n+\tFILE *f = fopen(input_file, \"r\");\n+\tif (!f)\n+\t\tdie(\"cannot read %s: %s\", input_file, strerror(errno));\n+\n+\twhile (fgets(line, sizeof(line), f)) {\n+\t\tuint32_t mark;\n+\t\tchar *line_end, *mark_end;\n+\t\tunsigned char sha1[20];\n+\t\tstruct object *object;\n+\n+\t\tline_end = strchr(line, '\\n');\n+\t\tif (line[0] != ':' || !line_end)\n+\t\t\tdie(\"corrupt mark line: %s\", line);\n+\t\t*line_end = 0;\n+\n+\t\tmark = strtoumax(line + 1, &mark_end, 10);\n+\t\tif (!mark || mark_end == line + 1\n+\t\t\t|| *mark_end != ' ' || get_sha1(mark_end + 1, sha1))\n+\t\t\tdie(\"corrupt mark line: %s\", line);\n+\n+\t\tobject = parse_object(sha1);\n+\t\tif (!object)\n+\t\t\tdie (\"Could not read blob %s\", sha1_to_hex(sha1));\n+\n+\t\tif (object->flags & SHOWN)\n+\t\t\terror(\"Object %s already has a mark\", sha1);\n+\n+\t\tmark_object(object, mark);\n+\t\tif (last_idnum < mark)\n+\t\t\tlast_idnum = mark;\n+\n+\t\tobject->flags |= SHOWN;\n+\t}\n+\tfclose(f);\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+\tchar *export_filename, *import_filename;\n \tstruct option options[] = {\n \t\tOPT_INTEGER(0, \"progress\", &progress,\n \t\t\t    \"show progress after <n> objects\"),\n \t\tOPT_CALLBACK(0, \"signed-tags\", &signed_tag_mode, \"mode\",\n \t\t\t     \"select handling of signed tags\",\n \t\t\t     parse_opt_signed_tag_mode),\n+\t\tOPT_STRING(0, \"export-marks\", &export_filename, \"FILE\",\n+\t\t\t     \"Dump marks to this file\"),\n+\t\tOPT_STRING(0, \"import-marks\", &import_filename, \"FILE\",\n+\t\t\t     \"Import marks from this file\"),\n \t\tOPT_END()\n \t};\n \n@@ -376,6 +457,9 @@ int cmd_fast_export(int argc, const char **argv, const char *prefix)\n \tif (argc > 1)\n \t\tusage_with_options (fast_export_usage, options);\n \n+\tif (import_filename)\n+\t\timport_marks(import_filename);\n+\n \tget_tags_and_duplicates(&revs.pending, &extra_refs);\n \n \tif (prepare_revision_walk(&revs))\n@@ -398,5 +482,8 @@ int cmd_fast_export(int argc, const char **argv, const char *prefix)\n \n \thandle_tags_and_duplicates(&extra_refs);\n \n+\tif (export_filename)\n+\t\texport_marks(export_filename);\n+\n \treturn 0;\n }\ndiff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh\nindex f09bfb1..60b5ee3 100755\n--- a/t/t9301-fast-export.sh\n+++ b/t/t9301-fast-export.sh\n@@ -78,6 +78,30 @@ test_expect_success 'iso-8859-1' '\n \t\t git cat-file commit i18n | grep \"Áéí óú\")\n \n '\n+test_expect_success 'import/export-marks' '\n+\n+\tgit checkout -b marks master &&\n+\tgit fast-export --export-marks=tmp-marks HEAD &&\n+\ttest -s tmp-marks &&\n+\tcp tmp-marks ~ &&\n+\ttest $(wc -l < tmp-marks) -eq 3 &&\n+\ttest $(\n+\t\tgit fast-export --import-marks=tmp-marks\\\n+\t\t--export-marks=tmp-marks HEAD |\n+\t\tgrep ^commit |\n+\t\twc -l) \\\n+\t-eq 0 &&\n+\techo change > file &&\n+\tgit commit -m \"last commit\" file &&\n+\ttest $(\n+\t\tgit fast-export --import-marks=tmp-marks \\\n+\t\t--export-marks=tmp-marks HEAD |\n+\t\tgrep ^commit\\  |\n+\t\twc -l) \\\n+\t-eq 1 &&\n+\ttest $(wc -l < tmp-marks) -eq 4\n+\n+'\n \n cat > signed-tag-import << EOF\n tag sign-your-name\n-- \n1.5.6.rc1.153.gc1d96\n"},{"id":"79444","messageId":"3BC2A14C-720C-4E78-B226-852AA28A3EE7@ai.rug.nl","threadId":"13802","inReplyTo":"1213183024-60013-1-git-send-email-pdebie@ai.rug.nl","subject":"Re: [PATCH v3] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-06-11T11:24:59Z","receivedAt":"2008-06-11T11:24:59Z","isPatch":true,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn 11 jun 2008, at 13:17, Pieter de Bie wrote:\n\n> +\tcp tmp-marks ~ &&\n\nbut beware this stray line.\n"},{"id":"79477","messageId":"alpine.DEB.1.00.0806111941160.1783@racer","threadId":"13802","inReplyTo":"1213183024-60013-1-git-send-email-pdebie@ai.rug.nl","subject":"Re: [PATCH v3] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-11T18:45:27Z","receivedAt":"2008-06-11T18:45:27Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Jun 2008, Pieter de Bie wrote:\n\n>   I actually had this new patch ready, but I was hoping Dscho would answer\n>   this first:\n>   \n> On 7 jun 2008, at 18:37, Junio C Hamano wrote:\n> >Oh, I was not complaining about the one-fourthness.  I was wondering why\n> >\"(uint32_t *)\", which makes it look like the type itself has very deep\n> >meaning for this computation, was used, instead of \"(char *)\" or something\n> >that makes it much clearer that what could be pointed at by the pointer\n> >does not matter and you are only using them as fake integers.  If there is\n> >such a deep meaning, it needs documented, and if there isn't then probably\n> >the use of (uint32_t *) should also be fixed.\n>   \n>   since I don't know the answer to that :)\n\nI think that your patch does not need to address that, as the logic is (or \nshould be) confined to the functions markt_object() and get_object_mark() \n(except that you have to split off mark_to_ptr() from \nmark_object(), as you did).\n\nUnfortunately, I did not yet have time to look up the discussion on the \nmailing list that led me to implement this funny pointer arithmetic.\n\nCiao,\nDscho\n"},{"id":"79486","messageId":"alpine.DEB.1.00.0806112043360.1783@racer","threadId":"13802","inReplyTo":"7vy75hnqu7.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v2] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-11T19:45:16Z","receivedAt":"2008-06-11T19:45:16Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 7 Jun 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > Okay, I looked again, and indeed, you _copied_ it.  Instead of using the \n> > functions mark_object() and get_object_mark() which are there only to be \n> > used by you.\n> >\n> > So please fix.\n> >\n> >> >Even if that is the case, doesn't \"(uint32_t *)deco->decoration - \n> >> >(uint32_t *)NULL\" mean the value range for deco->decoration is \n> >> >one-fourth of U32?\n> >\n> > It is.  But since every object needs already at least 20 bytes, and we do \n> > not even have the complete address space to put objects into, and we do \n> > not plan to support 64-bit only repositories, I think we are fine.\n> \n> Oh, I was not complaining about the one-fourthness.  I was wondering why \n> \"(uint32_t *)\", which makes it look like the type itself has very deep \n> meaning for this computation, was used, instead of \"(char *)\" or \n> something that makes it much clearer that what could be pointed at by \n> the pointer does not matter and you are only using them as fake \n> integers.\n\nProbably you are right.  I had the impression that you could not rely on \n(void *) having the full precision, but that was completely bogus.\n\nIt could be changed to (char *) safely.\n\nCiao,\nDscho\n"},{"id":"79510","messageId":"7vr6b3bqc5.fsf@gitster.siamese.dyndns.org","threadId":"13802","inReplyTo":"1213183024-60013-1-git-send-email-pdebie@ai.rug.nl","subject":"Re: [PATCH v3] builtin-fast-export: Add importing and exporting of revision marks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-11T21:43:06Z","receivedAt":"2008-06-11T21:43:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pieter de Bie <pdebie@ai.rug.nl> writes:\n\n> This adds the --import-marks and --export-marks to fast-export. These import\n> and export the marks used to for all revisions exported in a similar fashion\n> to what fast-import does. The format is the same as fast-import, so you can\n> create a bidirectional importer / exporter by using the same marks file on\n> both sides.\n\nHeh, I've long queued a fixed-up version in 'pu' as 4ba0575\n(builtin-fast-export: Add importing and exporting of revision marks,\n2008-06-05).\n\nI think renaming the \"mark_object\" to \"mark_next_object\" makes quite a lot\nof sense, and I do not have any preference between mark2deco vs mark_to_ptr \nnor between a macro vs a static inline function for something small like\nthese.\n\nYou still use export_filename and import_filename uninitialized in\ncmd_fast_export() and breaks everybody who does not use export-marks\noption.  Has this patch (and the previous one I fixed up before queuing it\nin 'pu') ever been tested?\n"}]}