{"thread":{"id":"37990","subject":"Getting a commit sha1 from fast-import in a remote-helper","startedAt":"2014-11-18T00:34:26Z","lastAt":"2014-11-19T02:36:34Z","messageCount":15,"participants":["Mike Hommey","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"252020","messageId":"20141118003426.GA6528@glandium.org","threadId":"37990","inReplyTo":null,"subject":"Getting a commit sha1 from fast-import in a remote-helper","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2014-11-18T00:34:26Z","receivedAt":"2014-11-18T00:34:26Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nFor some reason, I need to know the sha1 corresponding to some marks\nI'm putting in a fast-import stream. Unfortunately, this does not appear\nto be possible.\n- I'd rather not require a checkpoint to export marks each time I need\n such a sha1, and I'd rather not do that work that requires them after\n all the marks have been created (although currently, I'm forced to).\n- fast-import's cat-blob only allows to cat blobs, which, well, is kind\n of in its name; how about adding an equivalent to the git-cat-file\n command?\n- fast-import's `ls` command documentation about its output format\n mentions that the output may contain commits, so I tried the trick of\n creating a tree with commits, but fast-import then fails with:\n fatal: Not a blob (actually a commit)\n which I totally understand, but then I wonder why the documentation\n mentions it and how one would get a tree containing references to\n commits. I guess the documentation should be fixed.\n\nSo, while there's a possible solution with an equivalent to the\ngit-cat-file command if that'd be accepted, that's also overkill for my\nneed, which is to simply get the sha1 corresponding to a mark. Would you\nconsider a patch adding a command that allows such a resolution?\n\nCheers,\n\nMike\n"},{"id":"252037","messageId":"20141118014028.GF4336@google.com","threadId":"37990","inReplyTo":"20141118003426.GA6528@glandium.org","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-11-18T01:40:28Z","receivedAt":"2014-11-18T01:40:28Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Mike Hommey wrote:\n\n> - fast-import's `ls` command documentation about its output format\n> mentions that the output may contain commits, so I tried the trick of\n> creating a tree with commits, but fast-import then fails with:\n> fatal: Not a blob (actually a commit)\n> which I totally understand, but then I wonder why the documentation\n> mentions it and how one would get a tree containing references to\n> commits. I guess the documentation should be fixed.\n\nOdd. Here's what happens when I try:\n\n $ echo \"ls $(git rev-parse HEAD)\" | git fast-import --quiet\n fatal: Missing space after tree-ish: ls a4a226a366ab0a173ed9e5f70f2a95d0d21e54c5\n fast-import: dumping crash report to .git/fast_import_crash_14080\n $ echo \"ls $(git rev-parse HEAD) \" | git fast-import --quiet\n 040000 tree d3d38e7d71cb40ebbaf2798b01837b3de43fd4a1\n\nHow did you get that \"Not a blob\" message?\n\nI think a good fix would be to teach parse_ls a mode with no \nparameter. Something like this (untested; needs cleanup and tests):\n\nSigned-off-by: Jonathan Nieder \n\ndiff --git i/fast-import.c w/fast-import.c\nindex d0bd285..a9a46be 100644\n--- i/fast-import.c\n+++ w/fast-import.c\n@@ -278,6 +278,8 @@ struct recent_command {\n \tchar *buf;\n };\n \n+extern const char *tag_type;\n+\n /* Configured limits on output */\n static unsigned long max_depth = 10;\n static off_t max_packsize;\n@@ -3047,6 +3049,49 @@ static void parse_ls(const char *p, struct branch *b)\n \tstruct tree_entry *root = NULL;\n \tstruct tree_entry leaf = {NULL};\n \n+\t/* ls SP */\n+\tif (*p != '\"' && !strchr(p, ' ')) {\n+\t\tunsigned char sha1[20];\n+\t\tstruct object_entry *e;\n+\t\tstatic struct strbuf line = STRBUF_INIT;\n+\t\tconst char *type;\n+\n+\t\tif (*p == ':') {\t/* */\n+\t\t\te = find_mark(parse_mark_ref_eol(p));\n+\t\t\tif (!e)\n+\t\t\t\tdie(\"Unknown mark: %s\", command_buf.buf);\n+\t\t\thashcpy(sha1, e->idx.sha1);\n+\t\t} else {\t/* */\n+\t\t\tif (get_sha1_hex(p, sha1))\n+\t\t\t\tdie(\"Invalid dataref: %s\", command_buf.buf);\n+\t\t\te = find_object(sha1);\n+\t\t\tp += 40;\n+\t\t\tif (*p)\n+\t\t\t\tdie(\"Garbage after dataref: %s\", command_buf.buf);\n+\t\t}\n+\n+\t\tswitch (e->type) {\n+\t\tcase OBJ_COMMIT:\n+\t\t\ttype = commit_type;\n+\t\t\tbreak;\n+\t\tcase OBJ_TREE:\n+\t\t\ttype = tree_type;\n+\t\t\tbreak;\n+\t\tcase OBJ_BLOB:\n+\t\t\ttype = blob_type;\n+\t\t\tbreak;\n+\t\tcase OBJ_TAG:\n+\t\t\ttype = tag_type;\n+\t\t\tbreak;\n+\t\tdefault:\n+\t\t\tdie(\"Not a tree-ish: %s\", command_buf.buf);\n+\t\t}\n+\n+\t\tstrbuf_reset(&line);\n+\t\tstrbuf_addf(&line, \"%s %s\\n\", type, sha1_to_hex(sha1));\n+\t\tcat_blob_write(line.buf, line.len);\n+\t}\n+\n \t/* ls SP ( SP)? */\n \tif (*p == '\"') {\n \t\tif (!b)\n"},{"id":"252063","messageId":"20141118022137.GA8418@glandium.org","threadId":"37990","inReplyTo":"20141118003426.GA6528@glandium.org","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2014-11-18T02:21:37Z","receivedAt":"2014-11-18T02:21:37Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Nov 18, 2014 at 09:34:26AM +0900, Mike Hommey wrote:\n> Hi,\n> \n> For some reason, I need to know the sha1 corresponding to some marks\n> I'm putting in a fast-import stream. Unfortunately, this does not appear\n> to be possible.\n> - I'd rather not require a checkpoint to export marks each time I need\n> such a sha1, and I'd rather not do that work that requires them after\n> all the marks have been created (although currently, I'm forced to).\n\nBTW, if it so happens that all the operations that were done end up\ncreating objects that already existed for some reason, checkpoint\ndoesn't do anything, which is fine for the pack and tags, but not\nnecessarily so for export-marks.\n\nMike\n"},{"id":"252065","messageId":"20141118023112.GA14034@glandium.org","threadId":"37990","inReplyTo":"20141118014028.GF4336@google.com","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2014-11-18T02:31:12Z","receivedAt":"2014-11-18T02:31:12Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Nov 17, 2014 at 05:40:28PM -0800, Jonathan Nieder wrote:\n> Mike Hommey wrote:\n> \n> > - fast-import's `ls` command documentation about its output format\n> > mentions that the output may contain commits, so I tried the trick of\n> > creating a tree with commits, but fast-import then fails with:\n> > fatal: Not a blob (actually a commit)\n> > which I totally understand, but then I wonder why the documentation\n> > mentions it and how one would get a tree containing references to\n> > commits. I guess the documentation should be fixed.\n> \n> Odd. Here's what happens when I try:\n> \n> $ echo \"ls $(git rev-parse HEAD)\" | git fast-import --quiet\n> fatal: Missing space after tree-ish: ls a4a226a366ab0a173ed9e5f70f2a95d0d21e54c5\n> fast-import: dumping crash report to .git/fast_import_crash_14080\n> $ echo \"ls $(git rev-parse HEAD) \" | git fast-import --quiet\n> 040000 tree d3d38e7d71cb40ebbaf2798b01837b3de43fd4a1\n> \n> How did you get that \"Not a blob\" message?\n\nWhen trying to *create* a tree with a commit in it, so instead of giving\nthe mark for a blob to a filemodify command, giving a mark for a commit.\nThat is what fails with \"Not a blob\".\nSo it's not possible to create a tree with a reference to a commit, at\nleast with fast-import.\nBut, the documentation for the ls command says this:\n\n Output uses the same format as git ls-tree -- :\n\n SP ('blob' | 'tree' | 'commit') SP HT LF\n\nThe 'commit' string certainly seems it cannot be there.\n\n> I think a good fix would be to teach parse_ls a mode with no \n> parameter. Something like this (untested; needs cleanup and tests):\n\nThis would make both your commands output the same thing, right? It\nwouldn't help my case :)\n\nMike\n"},{"id":"252066","messageId":"20141118023520.GB14034@glandium.org","threadId":"37990","inReplyTo":"20141118022137.GA8418@glandium.org","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2014-11-18T02:35:20Z","receivedAt":"2014-11-18T02:35:20Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Nov 18, 2014 at 11:21:37AM +0900, Mike Hommey wrote:\n> On Tue, Nov 18, 2014 at 09:34:26AM +0900, Mike Hommey wrote:\n> > Hi,\n> > \n> > For some reason, I need to know the sha1 corresponding to some marks\n> > I'm putting in a fast-import stream. Unfortunately, this does not appear\n> > to be possible.\n> > - I'd rather not require a checkpoint to export marks each time I need\n> > such a sha1, and I'd rather not do that work that requires them after\n> > all the marks have been created (although currently, I'm forced to).\n> \n> BTW, if it so happens that all the operations that were done end up\n> creating objects that already existed for some reason, checkpoint\n> doesn't do anything, which is fine for the pack and tags, but not\n> necessarily so for export-marks.\n\nAnd while I'm here, it's sad that one needs to emit a dummy cat-blob or\nls command to wait for a checkpoint to be finished because they are the\nonly commands that trigger something written on the cat-blob fd that can\nbe waited for.\n\nMike.\n"},{"id":"252067","messageId":"20141118025131.GH4336@google.com","threadId":"37990","inReplyTo":"20141118023112.GA14034@glandium.org","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-11-18T02:51:31Z","receivedAt":"2014-11-18T02:51:31Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Mike Hommey wrote:\n> On Mon, Nov 17, 2014 at 05:40:28PM -0800, Jonathan Nieder wrote:\n\n>> How did you get that \"Not a blob\" message?\n>\n> When trying to *create* a tree with a commit in it, so instead of giving\n> the mark for a blob to a filemodify command, giving a mark for a commit.\n> That is what fails with \"Not a blob\".\n\nAh, I see what you were trying now. It's complaining that the data\nand mode don't match up. See under 'filemodify' in the manual.\n\nSomething like\n\n\tM 160000 :1 mycommit\n\nshould work fine, though that's a pretty ugly workaround for the\ninability to do\n\n\tls :1\n\n[...]\n>> I think a good fix would be to teach parse_ls a mode with no \n>> parameter. Something like this (untested; needs cleanup and tests):\n>\n> This would make both your commands output the same thing, right? It\n> wouldn't help my case :)\n\nIt's easily possible my patch has a typo somewhere, but the expected\noutput format would be\n\n\tcommit 6066a7eac4b2bcdb86971783b583e4e408b32e81\n\nThat wouldn't help?\n\nPuzzled,\nJonathan\n"},{"id":"252068","messageId":"20141118025359.GI4336@google.com","threadId":"37990","inReplyTo":"20141118022137.GA8418@glandium.org","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-11-18T02:53:59Z","receivedAt":"2014-11-18T02:53:59Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Mike Hommey wrote:\n\n> BTW, if it so happens that all the operations that were done end up\n> creating objects that already existed for some reason, checkpoint\n> doesn't do anything, which is fine for the pack and tags, but not\n> necessarily so for export-marks.\n\nDoes something like this help?\n\nDo you have a short script that can demonstrate the failure?\n\nLazily,\nJonathan\n\nSigned-off-by: Jonathan Nieder \n\ndiff --git i/fast-import.c w/fast-import.c\nindex d0bd285..c3d53c8 100644\n--- i/fast-import.c\n+++ w/fast-import.c\n@@ -3088,12 +3088,11 @@ static void parse_ls(const char *p, struct branch *b)\n static void checkpoint(void)\n {\n \tcheckpoint_requested = 0;\n-\tif (object_count) {\n+\tif (object_count)\n \t\tcycle_packfile();\n-\t\tdump_branches();\n-\t\tdump_tags();\n-\t\tdump_marks();\n-\t}\n+\tdump_branches();\n+\tdump_tags();\n+\tdump_marks();\n }\n \n static void parse_checkpoint(void)\n"},{"id":"252069","messageId":"20141118031147.GA15358@glandium.org","threadId":"37990","inReplyTo":"20141118025131.GH4336@google.com","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2014-11-18T03:11:47Z","receivedAt":"2014-11-18T03:11:47Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Nov 17, 2014 at 06:51:31PM -0800, Jonathan Nieder wrote:\n> Mike Hommey wrote:\n> > On Mon, Nov 17, 2014 at 05:40:28PM -0800, Jonathan Nieder wrote:\n> \n> >> How did you get that \"Not a blob\" message?\n> >\n> > When trying to *create* a tree with a commit in it, so instead of giving\n> > the mark for a blob to a filemodify command, giving a mark for a commit.\n> > That is what fails with \"Not a blob\".\n> \n> Ah, I see what you were trying now. It's complaining that the data\n> and mode don't match up. See under 'filemodify' in the manual.\n> \n> Something like\n> \n> \tM 160000 :1 mycommit\n> \n> should work fine, though that's a pretty ugly workaround for the\n> inability to do\n> \n> \tls :1\n\nActually, for my use, that ugly workaround actually improves things for\nme, avoiding to use blobs in some of the stuff I want to store :) How\ndid I miss that? Thanks a lot for the enlightenment.\n\n> [...]\n> >> I think a good fix would be to teach parse_ls a mode with no \n> >> parameter. Something like this (untested; needs cleanup and tests):\n> >\n> > This would make both your commands output the same thing, right? It\n> > wouldn't help my case :)\n> \n> It's easily possible my patch has a typo somewhere, but the expected\n> output format would be\n> \n> \tcommit 6066a7eac4b2bcdb86971783b583e4e408b32e81\n> \n> That wouldn't help?\n\nOh, so `ls ` would print out what is? That would\ndefinitely help, although with the trick above, I probably wouldn't\nactually need it anymore.\n\nMike\n"},{"id":"252070","messageId":"20141118031406.GB15358@glandium.org","threadId":"37990","inReplyTo":"20141118025359.GI4336@google.com","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2014-11-18T03:14:06Z","receivedAt":"2014-11-18T03:14:06Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Nov 17, 2014 at 06:53:59PM -0800, Jonathan Nieder wrote:\n> Mike Hommey wrote:\n> \n> > BTW, if it so happens that all the operations that were done end up\n> > creating objects that already existed for some reason, checkpoint\n> > doesn't do anything, which is fine for the pack and tags, but not\n> > necessarily so for export-marks.\n> \n> Does something like this help?\n\nI'm not sure about branches and tags, as they would mostly be noops,\nbut dump_marks definitely needs to happen. I did try to move dump_marks\nout of the if already, and that did what I wanted.\n\nMike\n"},{"id":"252071","messageId":"20141118032740.GJ4336@google.com","threadId":"37990","inReplyTo":"20141118023520.GB14034@glandium.org","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-11-18T03:27:41Z","receivedAt":"2014-11-18T03:27:41Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Mike Hommey wrote:\n\n> And while I'm here, it's sad that one needs to emit a dummy cat-blob or\n> ls command to wait for a checkpoint to be finished\n\nThat's a good point. (Though relying on checkpoints to read back\ninformation is an ugly trick, so if we can get other commands to\nprovide the information you need then that would be better.)\n\nThe old-fashioned way is to do \"progress checkpoint done\". Alas, that\nwrites to the progress fd, which doesn't go to the remote helper's\nstdin. How about something like this?\n\nSigned-off-by: Jonathan Nieder \n\ndiff --git i/Documentation/git-fast-import.txt w/Documentation/git-fast-import.txt\nindex 377eeaa..c0dedac 100644\n--- i/Documentation/git-fast-import.txt\n+++ w/Documentation/git-fast-import.txt\n@@ -1055,6 +1055,12 @@ ls::\n \trather than wasting time on the early part of an import\n \tbefore the unsupported command is detected.\n \n+notify-on-checkpoint::\n+\tCause the backend to write `checkpoint complete` to the file\n+\tdescriptor set with `--cat-blob-fd`, or to `stdout` if\n+\t`--cat-blob-fd` was unspecified, when finishing a checkpoint\n+\trequested via a `checkpoint` command or SIGUSR1.\n+\n notes::\n \tRequire that the backend support the 'notemodify' (N)\n \tsubcommand to the 'commit' command.\ndiff --git i/fast-import.c w/fast-import.c\nindex d0bd285..ccf4768 100644\n--- i/fast-import.c\n+++ w/fast-import.c\n@@ -329,6 +329,7 @@ static const char *import_marks_file;\n static int import_marks_file_from_stream;\n static int import_marks_file_ignore_missing;\n static int relative_marks_paths;\n+static int notify_on_checkpoint;\n \n /* Our last blob */\n static struct last_object last_blob = { STRBUF_INIT, 0, 0, 0 };\n@@ -3094,6 +3095,9 @@ static void checkpoint(void)\n \t\tdump_tags();\n \t\tdump_marks();\n \t}\n+\tif (notify_on_checkpoint)\n+\t\tcat_blob_write(\"checkpoint complete\\n\",\n+\t\t\t strlen(\"checkpoint complete\\n\"));\n }\n \n static void parse_checkpoint(void)\n@@ -3244,6 +3248,8 @@ static int parse_one_feature(const char *feature, int from_stream)\n \t\toption_export_marks(arg);\n \t} else if (!strcmp(feature, \"cat-blob\")) {\n \t\t; /* Don't die - this feature is supported */\n+\t} else if (!strcmp(feature, \"notify-on-checkpoint\")) {\n+\t\tnotify_on_checkpoint = 1;\n \t} else if (!strcmp(feature, \"relative-marks\")) {\n \t\trelative_marks_paths = 1;\n \t} else if (!strcmp(feature, \"no-relative-marks\")) {\n"},{"id":"252073","messageId":"20141118041757.GA15972@glandium.org","threadId":"37990","inReplyTo":"20141118032740.GJ4336@google.com","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2014-11-18T04:17:57Z","receivedAt":"2014-11-18T04:17:57Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Nov 17, 2014 at 07:27:41PM -0800, Jonathan Nieder wrote:\n> Mike Hommey wrote:\n> \n> > And while I'm here, it's sad that one needs to emit a dummy cat-blob or\n> > ls command to wait for a checkpoint to be finished\n> \n> That's a good point. (Though relying on checkpoints to read back\n> information is an ugly trick, so if we can get other commands to\n> provide the information you need then that would be better.)\n> \n> The old-fashioned way is to do \"progress checkpoint done\". Alas, that\n> writes to the progress fd, which doesn't go to the remote helper's\n> stdin. How about something like this?\n\nHow about something more generic, like \"sync\", which purpose would be to\nrequest synchronisation with fast-import, which would respond \"sync\" on\nthe cat-blob fd?\n\nOr \"ping\"<->\"pong\".\n\nAlthough... I wonder if that would really be useful for anything else\nthan checkpoint...\n\nThat said, I, for one, would be fine if this is not \"fixed\" as long as\nmarks can be resolved some other way (and, in fact, it may turn out that\nI don't need to resolve marks to sha1s at all)\n\nThanks for you help\n\nMike\n"},{"id":"252172","messageId":"20141119021824.GA9094@glandium.org","threadId":"37990","inReplyTo":"20141118031147.GA15358@glandium.org","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2014-11-19T02:18:24Z","receivedAt":"2014-11-19T02:18:24Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Nov 18, 2014 at 12:11:47PM +0900, Mike Hommey wrote:\n> Oh, so `ls ` would print out what is? That would\n> definitely help, although with the trick above, I probably wouldn't\n> actually need it anymore.\n\nSo, in the end, I was able to do everything with what's currently\nprovided by git fast-import, but one thing would probably make life\neasier for me: being able to initialize a commit tree from a commit\nthat's not one of the direct parents.\n\nBecause the data I'm using gives diffs against possibly unrelated\ncommits, and because starting a tree from scratch is actually slow when\nyou have thousands of subdirectories, it would be easier if I could just\nstart from that tree I have a diff against and apply the changes.\nWithout this, there would be a lot of `ls` command emitting involved,\nand I'm actually not sure that wouldn't be as slow as starting from\nscratch (haven't implemented yet, so I can't tell). Also, I'm not sure\nhow I'm supposed to know how much to read back from `ls`.\n\nMike\n"},{"id":"252173","messageId":"20141119022121.GU6527@google.com","threadId":"37990","inReplyTo":"20141119021824.GA9094@glandium.org","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-11-19T02:21:22Z","receivedAt":"2014-11-19T02:21:22Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Mike Hommey wrote:\n\n> So, in the end, I was able to do everything with what's currently\n> provided by git fast-import, but one thing would probably make life\n> easier for me: being able to initialize a commit tree from a commit\n> that's not one of the direct parents.\n\nIIRC then 'M 040000' wants a tree object, not a commit object, so\nyou'd have to do\n\n\tls \"\"\n\tM 040000 \"\"\n"},{"id":"252174","messageId":"20141119022759.GA9818@glandium.org","threadId":"37990","inReplyTo":"20141119022121.GU6527@google.com","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2014-11-19T02:27:59Z","receivedAt":"2014-11-19T02:27:59Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Nov 18, 2014 at 06:21:22PM -0800, Jonathan Nieder wrote:\n> Mike Hommey wrote:\n> \n> > So, in the end, I was able to do everything with what's currently\n> > provided by git fast-import, but one thing would probably make life\n> > easier for me: being able to initialize a commit tree from a commit\n> > that's not one of the direct parents.\n> \n> IIRC then 'M 040000' wants a tree object, not a commit object, so\n> you'd have to do\n> \n> \tls \"\"\n> \tM 040000 \"\"\n\nThat's what I'm planning to try ; Would doing:\nM 040000 \"\"\nM 0644 some/path\nD other/path\n\nwork? Or do I have to actually build a tree from the combination of the\noutput from various ls and those filedelete/filemodify?\n\nMike\n"},{"id":"252175","messageId":"20141119023634.GV6527@google.com","threadId":"37990","inReplyTo":"20141119022759.GA9818@glandium.org","subject":"Re: Getting a commit sha1 from fast-import in a remote-helper","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-11-19T02:36:34Z","receivedAt":"2014-11-19T02:36:34Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"On Wed, Nov 19, 2014 at 11:27:59AM +0900, Mike Hommey wrote:\n> On Tue, Nov 18, 2014 at 06:21:22PM -0800, Jonathan Nieder wrote:\n\n>> IIRC then 'M 040000' wants a tree object, not a commit object, so\n>> you'd have to do\n>>\n>> \tls \"\"\n>> \tM 040000 \"\"\n>\n> That's what I'm planning to try ; Would doing:\n> M 040000 \"\"\n> M 0644 some/path\n> D other/path\n>\n> work?\n\nYes, that should work fine. That's how contrib/svn-fe/svn-fe.c deals\nwith 'Node-copyfrom-rev' in Subversion dumpfiles, for what it's worth.\n"}]}