{"thread":{"id":"39369","subject":"recovering from \"unordered stage entries in index\" error","startedAt":"2015-05-19T13:48:05Z","lastAt":"2015-05-26T13:37:23Z","messageCount":17,"participants":["McHenry, Matt","Junio C Hamano","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"261553","messageId":"D377A9280DB18546A2471214D5CBB0E908599428C7@exchdb01","threadId":"39369","inReplyTo":null,"subject":"recovering from \"unordered stage entries in index\" error","fromName":"McHenry, Matt","fromEmail":"mmchenry@carnegielearning.com","sentAt":"2015-05-19T13:48:05Z","receivedAt":"2015-05-19T13:48:05Z","isPatch":false,"sender":{"key":"mmchenry@carnegielearning.com","avatar":"https://gravatar.com/avatar/2187a10f4f413a9b901f08107f275b70aa826c8f9bbe7c14fff4dae3ae58384b?d=mp&s=160"},"body":"\n\tI've just upgraded my git from 2.0.5 to 2.3.6, and I'm now unable to run 'git svn fetch' in one of my repositories:\n\n$ git svn fetch\nfatal: unordered stage entries in index\nwrite-tree: command returned error: 128\n\n\t'git status' shows a few untracked files but is otherwise clean.\n\n\tIt looks like this check was introduced in 15999d0be8179fb7a2e6eafb931d25ed65df50aa, with the summary \"read_index_from(): catch out of order entries when reading an index file\" (first appearing in 2.2.0).\n\n\tMailing list discussion looked like it implicated third-party tools. I don't recall running any other tools on this repo; it doesn't do much day-to-day other than a long series of 'git svn fetch'es. (But it's been around for a couple of years, so who knows.)\n\n\tAt any rate, what can I do to recover from this situation? I tried to locate a path with multiple index entries like this, but got no results:\n\n$ git ls-files -s | cut -f 2-100 | sort | uniq -c | grep -v '^[ \\t]*1 '\n\n\t(I originally posted on SO at http://stackoverflow.com/questions/30264826/; I'll update that with any solutions that come up here, to ease future googling.)\n"},{"id":"261555","messageId":"CAPc5daUtrfWrVeKMdF5sAA5pt5owkyqoZ-b=BoO=Oms0rYF1ag@mail.gmail.com","threadId":"39369","inReplyTo":"D377A9280DB18546A2471214D5CBB0E908599428C7@exchdb01","subject":"Re: recovering from \"unordered stage entries in index\" error","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-19T15:19:44Z","receivedAt":"2015-05-19T15:19:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Tue, May 19, 2015 at 6:48 AM, McHenry, Matt\n wrote:\n>\n> I've just upgraded my git from 2.0.5 to 2.3.6, and I'm now unable to run 'git svn fetch' in one of my repositories:\n>\n> $ git svn fetch\n> fatal: unordered stage entries in index\n> write-tree: command returned error: 128\n\nAre you by any chance using the split-index mode (which I think is\nbroken in 2.3.6)?\n"},{"id":"261566","messageId":"D377A9280DB18546A2471214D5CBB0E90859942B54@exchdb01","threadId":"39369","inReplyTo":"CAPc5daUtrfWrVeKMdF5sAA5pt5owkyqoZ-b=BoO=Oms0rYF1ag@mail.gmail.com","subject":"RE: recovering from \"unordered stage entries in index\" error","fromName":"McHenry, Matt","fromEmail":"mmchenry@carnegielearning.com","sentAt":"2015-05-19T16:51:14Z","receivedAt":"2015-05-19T16:51:14Z","isPatch":false,"sender":{"key":"mmchenry@carnegielearning.com","avatar":"https://gravatar.com/avatar/2187a10f4f413a9b901f08107f275b70aa826c8f9bbe7c14fff4dae3ae58384b?d=mp&s=160"},"body":"\n\tI had never heard of that. Google led me to the man page for 'git update-index --split-index', and after reading it, I think this demonstrates that I'm not using that feature:\n\n$ ls .git/*index*\n.git/index\n\n> -----Original Message-----\n> From: jch2355@gmail.com [mailto:jch2355@gmail.com] On Behalf Of Junio C\n> Hamano\n> Sent: Tuesday, May 19, 2015 11:20\n> To: McHenry, Matt\n> Cc: git@vger.kernel.org\n> Subject: Re: recovering from \"unordered stage entries in index\" error\n> \n> On Tue, May 19, 2015 at 6:48 AM, McHenry, Matt\n> wrote:\n> >\n> > I've just upgraded my git from 2.0.5 to 2.3.6, and I'm now\n> unable to run 'git svn fetch' in one of my repositories:\n> >\n> > $ git svn fetch\n> > fatal: unordered stage entries in index\n> > write-tree: command returned error: 128\n> \n> Are you by any chance using the split-index mode (which I think is\n> broken in 2.3.6)?\n"},{"id":"261769","messageId":"CACsJy8AS-9Cv6V=OKTckpnqd6OGsmvRy17TLoikT4QkA0sRofg@mail.gmail.com","threadId":"39369","inReplyTo":"D377A9280DB18546A2471214D5CBB0E908599428C7@exchdb01","subject":"Re: recovering from \"unordered stage entries in index\" error","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-05-21T09:56:44Z","receivedAt":"2015-05-21T09:56:44Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, May 19, 2015 at 8:48 PM, McHenry, Matt\n wrote:\n>\n>\n> I've just upgraded my git from 2.0.5 to 2.3.6, and I'm now unable to run 'git svn fetch' in one of my repositories:\n>\n> $ git svn fetch\n> fatal: unordered stage entries in index\n\nThis message can be improved to show what entries have this problem.\nBut then I don't see any way to recover the index manually. ls-files\nwill die too. Perhaps we should be gentle in this case: show warnings\ninstead of aborting the program and internally reorder the index. I\nthink, unless you have multiple entries with the same stage, the\nrecovered index should run well. The broken index could be renamed to\nindex.broken or something for later analysis, or we forbid writing the\nreordered index to disk.\n\nHmm?\n\n> write-tree: command returned error: 128\n>\n> 'git status' shows a few untracked files but is otherwise clean.\n>\n> It looks like this check was introduced in 15999d0be8179fb7a2e6eafb931d25ed65df50aa, with the summary \"read_index_from(): catch out of order entries when reading an index file\" (first appearing in 2.2.0).\n>\n> Mailing list discussion looked like it implicated third-party tools. I don't recall running any other tools on this repo; it doesn't do much day-to-day other than a long series of 'git svn fetch'es. (But it's been around for a couple of years, so who knows.)\n>\n> At any rate, what can I do to recover from this situation? I tried to locate a path with multiple index entries like this, but got no results:\n>\n> $ git ls-files -s | cut -f 2-100 | sort | uniq -c | grep -v '^[ \\t]*1 '\n>\n> (I originally posted on SO at http://stackoverflow.com/questions/30264826/; I'll update that with any solutions that come up here, to ease future googling.)\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\n\n\n\n-- \nDuy\n"},{"id":"261783","messageId":"D377A9280DB18546A2471214D5CBB0E908599F7E02@exchdb01","threadId":"39369","inReplyTo":"CACsJy8AS-9Cv6V=OKTckpnqd6OGsmvRy17TLoikT4QkA0sRofg@mail.gmail.com","subject":"RE: recovering from \"unordered stage entries in index\" error","fromName":"McHenry, Matt","fromEmail":"mmchenry@carnegielearning.com","sentAt":"2015-05-21T13:19:11Z","receivedAt":"2015-05-21T13:19:11Z","isPatch":false,"sender":{"key":"mmchenry@carnegielearning.com","avatar":"https://gravatar.com/avatar/2187a10f4f413a9b901f08107f275b70aa826c8f9bbe7c14fff4dae3ae58384b?d=mp&s=160"},"body":"> This message can be improved to show what entries have this problem.\n\n\tYes, that would definitely be a start. :)\n\n> But then I don't see any way to recover the index manually. ls-files\n> will die too. Perhaps we should be gentle in this case: show warnings\n\n\tActually, ls-files succeeds on my broken index:\n\n$ git ls-files > /dev/null\n$ echo $?\n0\n\n\tCould I do something with 'git read-tree' to force creation of a new valid index? I guess 'git clone' would work too, except that I have 'git svn' metadata that I'd need to preserve.\n\n> instead of aborting the program and internally reorder the index. I\n> think, unless you have multiple entries with the same stage, the\n> recovered index should run well. The broken index could be renamed to\n> index.broken or something for later analysis, or we forbid writing the\n> reordered index to disk.\n> \n> Hmm?\n> \n> > write-tree: command returned error: 128\n> >\n> > 'git status' shows a few untracked files but is otherwise clean.\n> >\n> > It looks like this check was introduced in\n> 15999d0be8179fb7a2e6eafb931d25ed65df50aa, with the summary\n> \"read_index_from(): catch out of order entries when reading an index file\"\n> (first appearing in 2.2.0).\n> >\n> > Mailing list discussion looked like it implicated third-party\n> tools. I don't recall running any other tools on this repo; it doesn't do\n> much day-to-day other than a long series of 'git svn fetch'es. (But it's\n> been around for a couple of years, so who knows.)\n> >\n> > At any rate, what can I do to recover from this situation? I\n> tried to locate a path with multiple index entries like this, but got no\n> results:\n> >\n> > $ git ls-files -s | cut -f 2-100 | sort | uniq -c | grep -v '^[ \\t]*1 '\n> >\n> > (I originally posted on SO at\n> http://stackoverflow.com/questions/30264826/; I'll update that with any\n> solutions that come up here, to ease future googling.)\n> > --\n> > To unsubscribe from this list: send the line \"unsubscribe git\" in\n> > the body of a message to majordomo@vger.kernel.org\n> > More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n> \n> \n> \n> --\n> Duy\n"},{"id":"261802","messageId":"xmqqwq01kh8r.fsf@gitster.dls.corp.google.com","threadId":"39369","inReplyTo":"CACsJy8AS-9Cv6V=OKTckpnqd6OGsmvRy17TLoikT4QkA0sRofg@mail.gmail.com","subject":"Re: recovering from \"unordered stage entries in index\" error","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-21T16:49:56Z","receivedAt":"2015-05-21T16:49:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> This message can be improved to show what entries have this problem.\n> But then I don't see any way to recover the index manually. ls-files\n> will die too.\n\nIsn't this failure coming from git-svn that tries to write out a\ntree after it prepared whatever it wants to record in its (possibly\ntemporary) index? I have a feeling that the index held by the end\nuser is not broken.\n"},{"id":"261867","messageId":"CACsJy8Bdx5tto0w1q7rZ1ORx8RmHZCEKPyBqYs37k=YvbO3kzA@mail.gmail.com","threadId":"39369","inReplyTo":"xmqqwq01kh8r.fsf@gitster.dls.corp.google.com","subject":"Re: recovering from \"unordered stage entries in index\" error","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-05-22T00:17:50Z","receivedAt":"2015-05-22T00:17:50Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, May 21, 2015 at 11:49 PM, Junio C Hamano wrote:\n> Duy Nguyen writes:\n>\n>> This message can be improved to show what entries have this problem.\n>> But then I don't see any way to recover the index manually. ls-files\n>> will die too.\n>\n> Isn't this failure coming from git-svn that tries to write out a\n> tree after it prepared whatever it wants to record in its (possibly\n> temporary) index? I have a feeling that the index held by the end\n> user is not broken.\n\nAhh that would explain why ls-files works. Yep.\n-- \nDuy\n"},{"id":"261938","messageId":"D377A9280DB18546A2471214D5CBB0E9087568F47B@exchdb01","threadId":"39369","inReplyTo":"CACsJy8Bdx5tto0w1q7rZ1ORx8RmHZCEKPyBqYs37k=YvbO3kzA@mail.gmail.com","subject":"RE: recovering from \"unordered stage entries in index\" error","fromName":"McHenry, Matt","fromEmail":"mmchenry@carnegielearning.com","sentAt":"2015-05-22T18:56:23Z","receivedAt":"2015-05-22T18:56:23Z","isPatch":false,"sender":{"key":"mmchenry@carnegielearning.com","avatar":"https://gravatar.com/avatar/2187a10f4f413a9b901f08107f275b70aa826c8f9bbe7c14fff4dae3ae58384b?d=mp&s=160"},"body":"> > Isn't this failure coming from git-svn that tries to write out a\n> > tree after it prepared whatever it wants to record in its (possibly\n> > temporary) index? I have a feeling that the index held by the end\n> > user is not broken.\n> \n> Ahh that would explain why ls-files works. Yep.\n\n\tI created a copy of this repo + wc via rsync and tried a couple of things. 'git svn rebase -l' worked fine, but didn't fix the error. Next, reset:\n\n$ git svn log --limit=1 | grep ^r\nr231655 | avuong | 2015-05-10 10:32:16 -0400 (Sun, 10 May 2015) | 2 lines\n\n$ git svn reset -r 231655 -p\nr231653 = 13a7f6d6a3f3e44ed1c8523b1a63d72fc4f0ddb9 (refs/remotes/trunk)\n\n$ git svn fetch\nfatal: unordered stage entries in index\nwrite-tree: command returned error: 128\n\n\tSo it doesn't seem to be specific to the revision being fetched. I could do a more drastic 'git svn reset', but as you can see I've already fetched a lot of revs, so I'd rather avoid re-fetching if possible.\n\n\tThanks for your help so far -- any other ideas (or requests for further debugging info) are appreciated!\n"},{"id":"261940","messageId":"CAPc5daVFA-FKTSUCRmb=JUr=H9ECtK8nJB3nyxHprCcJ+0CHBQ@mail.gmail.com","threadId":"39369","inReplyTo":"D377A9280DB18546A2471214D5CBB0E908599428C7@exchdb01","subject":"Re: recovering from \"unordered stage entries in index\" error","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-22T19:24:53Z","receivedAt":"2015-05-22T19:24:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The message \"unordered stage entries in index\" comes only when\ntwo adjacent entries in the index are in a wrong order, e.g. \"test0\"\nshould come before \"test1\" but somehow the index records them\nin the other way around. Doing something like this:\n\n$ git ls-files >Q\n$ LANG=C LC_ALL=C sort Q >R\n$ diff Q R\n\nmay tell you which entries are wrong, even though it wouldn't show\nwho made them wrong.\n\n(pardon top-posting, overlong lines and typos; sent from GMail web UI)\n\nOn Tue, May 19, 2015 at 6:48 AM, McHenry, Matt\n wrote:\n>\n> I've just upgraded my git from 2.0.5 to 2.3.6, and I'm now unable to run 'git svn fetch' in one of my repositories:\n>\n> $ git svn fetch\n> fatal: unordered stage entries in index\n> write-tree: command returned error: 128\n>\n> 'git status' shows a few untracked files but is otherwise clean.\n>\n> It looks like this check was introduced in 15999d0be8179fb7a2e6eafb931d25ed65df50aa, with the summary \"read_index_from(): catch out of order entries when reading an index file\" (first appearing in 2.2.0).\n>\n> Mailing list discussion looked like it implicated third-party tools. I don't recall running any other tools on this repo; it doesn't do much day-to-day other than a long series of 'git svn fetch'es. (But it's been around for a couple of years, so who knows.)\n>\n> At any rate, what can I do to recover from this situation? I tried to locate a path with multiple index entries like this, but got no results:\n>\n> $ git ls-files -s | cut -f 2-100 | sort | uniq -c | grep -v '^[ \\t]*1 '\n>\n> (I originally posted on SO at http://stackoverflow.com/questions/30264826/; I'll update that with any solutions that come up here, to ease future googling.)\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"261943","messageId":"D377A9280DB18546A2471214D5CBB0E9087568F50D@exchdb01","threadId":"39369","inReplyTo":"CAPc5daVFA-FKTSUCRmb=JUr=H9ECtK8nJB3nyxHprCcJ+0CHBQ@mail.gmail.com","subject":"RE: recovering from \"unordered stage entries in index\" error","fromName":"McHenry, Matt","fromEmail":"mmchenry@carnegielearning.com","sentAt":"2015-05-22T19:57:40Z","receivedAt":"2015-05-22T19:57:40Z","isPatch":false,"sender":{"key":"mmchenry@carnegielearning.com","avatar":"https://gravatar.com/avatar/2187a10f4f413a9b901f08107f275b70aa826c8f9bbe7c14fff4dae3ae58384b?d=mp&s=160"},"body":"\n\tYes, that does turn up some interesting stuff. It looks like the repository contains some paths with non-ASCII characters, for example this one has some en-dashes (U+2013) in its name:\n\n$ svn ls -R svn://dev/trunk/curriculum/Fluency | grep Ninja__Beta\nHurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 – Ninja/FT3 – Ninja__Beta.zip\n\n$ svn ls -R svn://dev/trunk/curriculum/Fluency | grep Ninja__Beta | od -cx\n0000000 H u r i x w o r k / s o u r c\n 7548 6972 2078 6f77 6b72 732f 756f 6372\n0000020 e f r o m M a y 2 0 1 4 /\n 2065 7266 6d6f 4d20 7961 3220 3130 2f34\n0000040 F o r _ A n e s h / 0 6 D e l\n 6f46 5f72 6e41 7365 2f68 3630 4420 6c65\n0000060 i v e r a b l e s / P h a s e\n 7669 7265 6261 656c 2f73 6850 7361 2065\n0000100 2 / F T 3 342 200 223 N i n j a /\n 2f32 5446 2033 80e2 2093 694e 6a6e 2f61\n0000120 F T 3 342 200 223 N i n j a _ _ B\n 5446 2033 80e2 2093 694e 6a6e 5f61 425f\n0000140 e t a . z i p \\n\n 7465 2e61 697a 0a70\n0000150\n\n\tIn the output of 'git ls-files', those paths appear quoted (there are almost 100 of them):\n\n$ git ls-files | grep Ninja__Beta\n\"curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \\342\\200\\223 Ninja/FT3 \\342\\200\\223 Ninja__Beta.zip\"\n\n$ git ls-files | grep ^\\\" | wc -l\n89\n\n\n\tIn the diff you suggested, 'sort' puts those paths at the absolute top of the list, while plain old ls-files puts them inline with the rest of the contents of the curriculum/ subdir:\n\n$ grep -n Ninja__Beta Q R\nQ:36109:\"curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \\342\\200\\223 Ninja/FT3 \\342\\200\\223 Ninja__Beta.zip\"\nR:89:\"curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \\342\\200\\223 Ninja/FT3 \\342\\200\\223 Ninja__Beta.zip\"\n\n\tAlso, I have the curriculum/Fluency/ directory marked as sparse-checkout:\n\n$ cat .git/info/sparse-checkout\n/*\n!/curriculum/Fluency/\n!/curriculum/Problems/lisp/\n!/curriculum/Problems/lisp_es/\n!/curriculum/Problems/sdk/Geometry/\n!/curriculum/Problems/sdk_es/Geometry/\n!/curriculum/Problems/sdk/Test-Questions/\n!/curriculum/Problems/sdk_es/Test-Questions/\n!/curriculum/Problems/sdk/Grammar/\n\n\n\tHowever, I tried to construct a test case that would reproduce this with a simple SVN repo containing a file created by 'touch \"make-git-svn-$(echo -e '\\u201c')unhappy$(echo -e '\\u201d')\"', but could not get it to fail. So there may be something more subtle going on here ...\n\n\n> -----Original Message-----\n> From: jch2355@gmail.com [mailto:jch2355@gmail.com] On Behalf Of Junio C\n> Hamano\n> Sent: Friday, May 22, 2015 15:25\n> To: McHenry, Matt\n> Cc: git@vger.kernel.org\n> Subject: Re: recovering from \"unordered stage entries in index\" error\n> \n> The message \"unordered stage entries in index\" comes only when\n> two adjacent entries in the index are in a wrong order, e.g. \"test0\"\n> should come before \"test1\" but somehow the index records them\n> in the other way around. Doing something like this:\n> \n> $ git ls-files >Q\n> $ LANG=C LC_ALL=C sort Q >R\n> $ diff Q R\n> \n> may tell you which entries are wrong, even though it wouldn't show\n> who made them wrong.\n> \n> (pardon top-posting, overlong lines and typos; sent from GMail web UI)\n> \n> On Tue, May 19, 2015 at 6:48 AM, McHenry, Matt\n> wrote:\n> >\n> > I've just upgraded my git from 2.0.5 to 2.3.6, and I'm now\n> unable to run 'git svn fetch' in one of my repositories:\n> >\n> > $ git svn fetch\n> > fatal: unordered stage entries in index\n> > write-tree: command returned error: 128\n> >\n> > 'git status' shows a few untracked files but is otherwise clean.\n> >\n> > It looks like this check was introduced in\n> 15999d0be8179fb7a2e6eafb931d25ed65df50aa, with the summary\n> \"read_index_from(): catch out of order entries when reading an index file\"\n> (first appearing in 2.2.0).\n> >\n> > Mailing list discussion looked like it implicated third-party\n> tools. I don't recall running any other tools on this repo; it doesn't do\n> much day-to-day other than a long series of 'git svn fetch'es. (But it's\n> been around for a couple of years, so who knows.)\n> >\n> > At any rate, what can I do to recover from this situation? I\n> tried to locate a path with multiple index entries like this, but got no\n> results:\n> >\n> > $ git ls-files -s | cut -f 2-100 | sort | uniq -c | grep -v '^[ \\t]*1 '\n> >\n> > (I originally posted on SO at\n> http://stackoverflow.com/questions/30264826/; I'll update that with any\n> solutions that come up here, to ease future googling.)\n> > --\n> > To unsubscribe from this list: send the line \"unsubscribe git\" in\n> > the body of a message to majordomo@vger.kernel.org\n> > More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"261979","messageId":"CACsJy8As8-b6kWHDnmAwAftyPG6X-BmoQdToQywzn9D4dtg2Fg@mail.gmail.com","threadId":"39369","inReplyTo":"D377A9280DB18546A2471214D5CBB0E9087568F47B@exchdb01","subject":"Re: recovering from \"unordered stage entries in index\" error","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-05-23T02:06:41Z","receivedAt":"2015-05-23T02:06:41Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, May 23, 2015 at 1:56 AM, McHenry, Matt\n wrote:\n> $ git svn fetch\n> fatal: unordered stage entries in index\n> write-tree: command returned error: 128\n\ngit-svn does not create the index manually. It uses update-index or\nread-tree to do that. While there's still a chance of bugs in\nupdate-index that produces broken index, it's probably read-tree in\nthis case because it assumes good order from the source tree object,\nwhich is(?) generated by git-svn. And the write-tree message supports\nthis (the code does read-tree then write-tree).\n\nSo maybe you can do \"GIT_TRACE=2 git svn fetch\" and post the output.\nI'd expect to see something like \"git read-tree \" before \"fatal:\nunorder...\". You can then use git ls-tree to examine this tree,\ntry to sort the file list with \"LANG=C sort\" and compare with the\noriginal list.\n-- \nDuy\n"},{"id":"261981","messageId":"D377A9280DB18546A2471214D5CBB0E9087568F592@exchdb01","threadId":"39369","inReplyTo":"CACsJy8As8-b6kWHDnmAwAftyPG6X-BmoQdToQywzn9D4dtg2Fg@mail.gmail.com","subject":"RE: recovering from \"unordered stage entries in index\" error","fromName":"McHenry, Matt","fromEmail":"mmchenry@carnegielearning.com","sentAt":"2015-05-23T02:47:18Z","receivedAt":"2015-05-23T02:47:18Z","isPatch":false,"sender":{"key":"mmchenry@carnegielearning.com","avatar":"https://gravatar.com/avatar/2187a10f4f413a9b901f08107f275b70aa826c8f9bbe7c14fff4dae3ae58384b?d=mp&s=160"},"body":"> So maybe you can do \"GIT_TRACE=2 git svn fetch\" and post the output.\n> I'd expect to see something like \"git read-tree \" before \"fatal:\n> unorder...\". You can then use git ls-tree to examine this tree,\n> try to sort the file list with \"LANG=C sort\" and compare with the\n> original list.\n\n\tThere is no read-tree in the output (below). The sha1 that is mentioned, 74332b7, is the one for the current trunk:\n\n$ git svn log -1 --show-commit --oneline trunk\nr231655 | 74332b7 | CLT: changed skill from not compound to compound.\n\n\tSo not surprisingly, I guess, I get basically the same results as with the ls-files commands earlier: files with Unicode chars are quoted and sort at the front:\n\n$ git ls-tree --name-only -r 74332b7d653cde7ba3b999cc7b0adcfd9d924440 > ls-tree\n$ LANG=C LC_ALL=C sort ls-tree > ls-tree-sorted-lc-all\n$ grep -n Ninja__Beta ls-tree*\nls-tree:36974:\"curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \\342\\200\\223 Ninja/FT3 \\342\\200\\223 Ninja__Beta.zip\"\nls-tree-sorted-lc-all:89:\"curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \\342\\200\\223 Ninja/FT3 \\342\\200\\223 Ninja__Beta.zip\"\n\n\t(Just sorting with LANG=C but without LC_ALL=C produced a ton of other differences, mostly around numeric vs. lexical ordering as far as I could tell.)\n\n\tI tried this same thing with my test repo, and it exhibits the same quoted-filename-sorts-to-the-top behaviour, but does not exhibit the git svn fetch write-tree error.\n\n\n$ GIT_TRACE=2 git svn fetch\n22:21:16.683918 git.c:557 trace: exec: 'git-svn' 'fetch'\n22:21:16.683945 run-command.c:351 trace: run_command: 'git-svn' 'fetch'\n02:21:16.918593 git.c:348 trace: built-in: git 'rev-parse' '--git-dir'\n02:21:16.920218 git.c:348 trace: built-in: git 'rev-parse' '--show-cdup'\n02:21:16.921997 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.fetchall'\n02:21:16.923609 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.repack'\n02:21:16.925164 git.c:348 trace: built-in: git 'config' '--get' 'svn.repackflags'\n02:21:16.926706 git.c:348 trace: built-in: git 'config' '--get' 'svn.revision'\n02:21:16.928847 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.nocheckout'\n02:21:16.930410 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvnsyncProps'\n02:21:16.931963 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.localtime'\n02:21:16.933538 git.c:348 trace: built-in: git 'config' '--get' 'svn.includepaths'\n02:21:16.935107 git.c:348 trace: built-in: git 'config' '--get' 'svn.username'\n02:21:16.936675 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noauthcache'\n02:21:16.940413 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.quiet'\n02:21:16.942064 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.uselogauthor'\n02:21:16.943696 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noMetadata'\n02:21:16.945344 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvmProps'\n02:21:16.947607 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.parent'\n02:21:16.950737 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.addauthorfrom'\n02:21:16.952532 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsprog'\n02:21:16.954133 git.c:348 trace: built-in: git 'config' '--get' 'svn.ignorepaths'\n02:21:16.955704 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.followparent'\n02:21:16.957287 git.c:348 trace: built-in: git 'config' '--get' 'svn.configdir'\n02:21:16.958930 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsfile'\n02:21:16.962142 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.logwindowsize'\n02:21:16.963913 git.c:348 trace: built-in: git 'config' '--get' 'svn.ignorerefs'\n02:21:16.966130 git.c:348 trace: built-in: git 'rev-parse' '--symbolic' '--all'\n02:21:16.970537 git.c:348 trace: built-in: git 'config' '-l'\n02:21:16.972410 git.c:348 trace: built-in: git 'config' '-l'\n02:21:16.974187 git.c:348 trace: built-in: git 'config' '--bool' 'svn.useSvmProps'\n02:21:16.976074 git.c:348 trace: built-in: git 'config' '-l'\n02:21:17.136056 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn-remote.svn.branches-maxRev'\n02:21:17.137928 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn-remote.svn.tags-maxRev'\n02:21:17.140124 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.url'\n02:21:17.142192 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.pushurl'\n02:21:17.144203 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.uuid'\n02:21:17.149689 git.c:348 trace: built-in: git 'rev-list' '--pretty=raw' '--reverse' '74332b7d653cde7ba3b999cc7b0adcfd9d924440..refs/remotes/trunk' '--'\n02:21:17.152412 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteRoot'\n02:21:17.154482 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteUUID'\n02:21:17.160391 git.c:348 trace: built-in: git 'cat-file' '--batch'\n02:21:17.582641 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.branches-maxRev' '231655'\n02:21:17.585237 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.tags-maxRev' '231655'\n02:21:17.590152 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.usesvmprops'\n02:21:17.592063 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.nometadata'\n02:21:17.593997 git.c:348 trace: built-in: git 'cat-file' 'commit' '74332b7d653cde7ba3b999cc7b0adcfd9d924440'\n02:21:17.596529 git.c:348 trace: built-in: git 'write-tree'\nfatal: unordered stage entries in index\nwrite-tree: command returned error: 128\n\n"},{"id":"261997","messageId":"xmqqsiancjg6.fsf@gitster.dls.corp.google.com","threadId":"39369","inReplyTo":"D377A9280DB18546A2471214D5CBB0E9087568F50D@exchdb01","subject":"Re: recovering from \"unordered stage entries in index\" error","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-23T17:06:17Z","receivedAt":"2015-05-23T17:06:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"McHenry, Matt\" writes:\n\n> \tYes, that does turn up some interesting stuff. It looks\n> \tlike the repository contains some paths with non-ASCII\n> \tcharacters, for example this one has some en-dashes (U+2013)\n> \tin its name:\n\nThen the recipe in the message you are responding to shoulld be\nchanged somewhat to tell Git that it is OK to show non-ASCII in\nverbatim.\n\nPerhaps doing this once\n\n git config core.quotepath false\n\nbefore asking ls-files to show the paths should be sufficient.\n\nThanks.\n"},{"id":"262005","messageId":"D377A9280DB18546A2471214D5CBB0E90875A547E6@exchdb01","threadId":"39369","inReplyTo":"805ACAFCB18CC2408F45D98ABEC64B650A06EC538B@exchdb01","subject":"RE: recovering from \"unordered stage entries in index\" error","fromName":"McHenry, Matt","fromEmail":"mmchenry@carnegielearning.com","sentAt":"2015-05-23T21:36:32Z","receivedAt":"2015-05-23T21:36:32Z","isPatch":false,"sender":{"key":"mmchenry@carnegielearning.com","avatar":"https://gravatar.com/avatar/2187a10f4f413a9b901f08107f275b70aa826c8f9bbe7c14fff4dae3ae58384b?d=mp&s=160"},"body":"\nPer Junio's email, with core.quotepath=false, there are no differences with sorting in either ls-files or the tree named in the GIT_TRACE_2 output:\n\n$ git config --local core.quotepath false\n\n$ git ls-tree --name-only -r 74332b7d653cde7ba3b999cc7b0adcfd9d924440 > ls-tree\n$ LANG=C LC_ALL=C sort ls-tree > ls-tree-sorted-lc-all\n$ diff -s ls-tree ls-tree-sorted-lc-all \nFiles ls-tree and ls-tree-sorted-lc-all are identical\n\n$ git ls-files > ls-files\n$ LANG=C LC_ALL=C sort ls-files > ls-files-sorted-lc-all\n$ diff -s ls-files ls-files-sorted-lc-all \nFiles ls-files and ls-files-sorted-lc-all are identical\n\n\n________________________________________\nFrom: McHenry, Matt\nSent: Friday, May 22, 2015 10:47 PM\nTo: Duy Nguyen\nCc: Junio C Hamano; git@vger.kernel.org\nSubject: RE: recovering from \"unordered stage entries in index\" error\n\n> So maybe you can do \"GIT_TRACE=2 git svn fetch\" and post the output.\n> I'd expect to see something like \"git read-tree \" before \"fatal:\n> unorder...\". You can then use git ls-tree to examine this tree,\n> try to sort the file list with \"LANG=C sort\" and compare with the\n> original list.\n\n There is no read-tree in the output (below). The sha1 that is mentioned, 74332b7, is the one for the current trunk:\n\n$ git svn log -1 --show-commit --oneline trunk\nr231655 | 74332b7 | CLT: changed skill from not compound to compound.\n\n So not surprisingly, I guess, I get basically the same results as with the ls-files commands earlier: files with Unicode chars are quoted and sort at the front:\n\n$ git ls-tree --name-only -r 74332b7d653cde7ba3b999cc7b0adcfd9d924440 > ls-tree\n$ LANG=C LC_ALL=C sort ls-tree > ls-tree-sorted-lc-all\n$ grep -n Ninja__Beta ls-tree*\nls-tree:36974:\"curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \\342\\200\\223 Ninja/FT3 \\342\\200\\223 Ninja__Beta.zip\"\nls-tree-sorted-lc-all:89:\"curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \\342\\200\\223 Ninja/FT3 \\342\\200\\223 Ninja__Beta.zip\"\n\n (Just sorting with LANG=C but without LC_ALL=C produced a ton of other differences, mostly around numeric vs. lexical ordering as far as I could tell.)\n\n I tried this same thing with my test repo, and it exhibits the same quoted-filename-sorts-to-the-top behaviour, but does not exhibit the git svn fetch write-tree error.\n\n\n$ GIT_TRACE=2 git svn fetch\n22:21:16.683918 git.c:557 trace: exec: 'git-svn' 'fetch'\n22:21:16.683945 run-command.c:351 trace: run_command: 'git-svn' 'fetch'\n02:21:16.918593 git.c:348 trace: built-in: git 'rev-parse' '--git-dir'\n02:21:16.920218 git.c:348 trace: built-in: git 'rev-parse' '--show-cdup'\n02:21:16.921997 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.fetchall'\n02:21:16.923609 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.repack'\n02:21:16.925164 git.c:348 trace: built-in: git 'config' '--get' 'svn.repackflags'\n02:21:16.926706 git.c:348 trace: built-in: git 'config' '--get' 'svn.revision'\n02:21:16.928847 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.nocheckout'\n02:21:16.930410 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvnsyncProps'\n02:21:16.931963 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.localtime'\n02:21:16.933538 git.c:348 trace: built-in: git 'config' '--get' 'svn.includepaths'\n02:21:16.935107 git.c:348 trace: built-in: git 'config' '--get' 'svn.username'\n02:21:16.936675 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noauthcache'\n02:21:16.940413 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.quiet'\n02:21:16.942064 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.uselogauthor'\n02:21:16.943696 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noMetadata'\n02:21:16.945344 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvmProps'\n02:21:16.947607 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.parent'\n02:21:16.950737 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.addauthorfrom'\n02:21:16.952532 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsprog'\n02:21:16.954133 git.c:348 trace: built-in: git 'config' '--get' 'svn.ignorepaths'\n02:21:16.955704 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.followparent'\n02:21:16.957287 git.c:348 trace: built-in: git 'config' '--get' 'svn.configdir'\n02:21:16.958930 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsfile'\n02:21:16.962142 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.logwindowsize'\n02:21:16.963913 git.c:348 trace: built-in: git 'config' '--get' 'svn.ignorerefs'\n02:21:16.966130 git.c:348 trace: built-in: git 'rev-parse' '--symbolic' '--all'\n02:21:16.970537 git.c:348 trace: built-in: git 'config' '-l'\n02:21:16.972410 git.c:348 trace: built-in: git 'config' '-l'\n02:21:16.974187 git.c:348 trace: built-in: git 'config' '--bool' 'svn.useSvmProps'\n02:21:16.976074 git.c:348 trace: built-in: git 'config' '-l'\n02:21:17.136056 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn-remote.svn.branches-maxRev'\n02:21:17.137928 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn-remote.svn.tags-maxRev'\n02:21:17.140124 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.url'\n02:21:17.142192 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.pushurl'\n02:21:17.144203 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.uuid'\n02:21:17.149689 git.c:348 trace: built-in: git 'rev-list' '--pretty=raw' '--reverse' '74332b7d653cde7ba3b999cc7b0adcfd9d924440..refs/remotes/trunk' '--'\n02:21:17.152412 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteRoot'\n02:21:17.154482 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteUUID'\n02:21:17.160391 git.c:348 trace: built-in: git 'cat-file' '--batch'\n02:21:17.582641 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.branches-maxRev' '231655'\n02:21:17.585237 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.tags-maxRev' '231655'\n02:21:17.590152 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.usesvmprops'\n02:21:17.592063 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.nometadata'\n02:21:17.593997 git.c:348 trace: built-in: git 'cat-file' 'commit' '74332b7d653cde7ba3b999cc7b0adcfd9d924440'\n02:21:17.596529 git.c:348 trace: built-in: git 'write-tree'\nfatal: unordered stage entries in index\nwrite-tree: command returned error: 128\n"},{"id":"262016","messageId":"CACsJy8B=ttGa1aBKTdZAe6bLN4rbEE1r3fA+ifNNvUWhYD0Yfg@mail.gmail.com","threadId":"39369","inReplyTo":"D377A9280DB18546A2471214D5CBB0E9087568F592@exchdb01","subject":"Re: recovering from \"unordered stage entries in index\" error","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-05-24T09:52:37Z","receivedAt":"2015-05-24T09:52:37Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, May 23, 2015 at 9:47 AM, McHenry, Matt\n wrote:\n>> So maybe you can do \"GIT_TRACE=2 git svn fetch\" and post the output.\n>> I'd expect to see something like \"git read-tree \" before \"fatal:\n>> unorder...\". You can then use git ls-tree to examine this tree,\n>> try to sort the file list with \"LANG=C sort\" and compare with the\n>> original list.\n>\n> There is no read-tree in the output (below). The sha1 that is mentioned, 74332b7, is the one for the current trunk:\n\nHm.. neither read-tree nor update-index is in the output. I can see\ngit-svn closing stderr sometimes, but not sure if that's why we don't\nsee these commands, or something else. Could you try again with\nGIT_TRACE=/absolute/path/to/some/where instead of GIT_TRACE=2 and post\nthe content of /abso../some/where?\n-- \nDuy\n"},{"id":"262121","messageId":"D377A9280DB18546A2471214D5CBB0E9087568F735@exchdb01","threadId":"39369","inReplyTo":"CACsJy8B=ttGa1aBKTdZAe6bLN4rbEE1r3fA+ifNNvUWhYD0Yfg@mail.gmail.com","subject":"RE: recovering from \"unordered stage entries in index\" error","fromName":"McHenry, Matt","fromEmail":"mmchenry@carnegielearning.com","sentAt":"2015-05-26T13:28:33Z","receivedAt":"2015-05-26T13:28:33Z","isPatch":false,"sender":{"key":"mmchenry@carnegielearning.com","avatar":"https://gravatar.com/avatar/2187a10f4f413a9b901f08107f275b70aa826c8f9bbe7c14fff4dae3ae58384b?d=mp&s=160"},"body":"> see these commands, or something else. Could you try again with\n> GIT_TRACE=/absolute/path/to/some/where instead of GIT_TRACE=2 and post\n> the content of /abso../some/where?\n\n\tIt looks the same as far as I can see:\n\n$ GIT_TRACE=/tmp/git-trace git svn fetch\nfatal: unordered stage entries in index\nwrite-tree: command returned error: 128\n\n$ egrep -i 'read|tree|update|index' /tmp/git-trace\n13:26:08.169921 git.c:348 trace: built-in: git 'write-tree'\n\n$ cat /tmp/git-trace\n09:26:07.402735 git.c:557 trace: exec: 'git-svn' 'fetch'\n09:26:07.402784 run-command.c:351 trace: run_command: 'git-svn' 'fetch'\n09:26:07.688866 git.c:348 trace: built-in: git 'rev-parse' '--show-prefix'\n13:26:07.691207 git.c:348 trace: built-in: git 'rev-parse' '--git-dir'\n13:26:07.693228 git.c:348 trace: built-in: git 'rev-parse' '--show-cdup'\n13:26:07.695594 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.quiet'\n13:26:07.697279 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsprog'\n13:26:07.699030 git.c:348 trace: built-in: git 'config' '--get' 'svn.ignorepaths'\n13:26:07.700914 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsfile'\n13:26:07.702872 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.followparent'\n13:26:07.704949 git.c:348 trace: built-in: git 'config' '--get' 'svn.configdir'\n13:26:07.706674 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.localtime'\n13:26:07.708590 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvmProps'\n13:26:07.710669 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvnsyncProps'\n13:26:07.712602 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noauthcache'\n13:26:07.714527 git.c:348 trace: built-in: git 'config' '--get' 'svn.username'\n13:26:07.716257 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.logwindowsize'\n13:26:07.717872 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noMetadata'\n13:26:07.719905 git.c:348 trace: built-in: git 'config' '--get' 'svn.ignorerefs'\n13:26:07.721623 git.c:348 trace: built-in: git 'config' '--get' 'svn.includepaths'\n13:26:07.723485 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.nocheckout'\n13:26:07.725441 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.addauthorfrom'\n13:26:07.727125 git.c:348 trace: built-in: git 'config' '--get' 'svn.repackflags'\n13:26:07.729179 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.repack'\n13:26:07.731143 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.uselogauthor'\n13:26:07.733139 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.parent'\n13:26:07.734911 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.fetchall'\n13:26:07.736992 git.c:348 trace: built-in: git 'config' '--get' 'svn.revision'\n13:26:07.739398 git.c:348 trace: built-in: git 'rev-parse' '--symbolic' '--all'\n13:26:07.744514 git.c:348 trace: built-in: git 'config' '-l'\n13:26:07.746770 git.c:348 trace: built-in: git 'config' '-l'\n13:26:07.749108 git.c:348 trace: built-in: git 'config' '--bool' 'svn.useSvmProps'\n13:26:07.751613 git.c:348 trace: built-in: git 'config' '-l'\n13:26:07.907707 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn-remote.svn.branches-maxRev'\n13:26:07.910171 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn-remote.svn.tags-maxRev'\n13:26:07.912608 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.url'\n13:26:07.915539 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.pushurl'\n13:26:07.917825 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.uuid'\n13:26:07.919620 git.c:348 trace: built-in: git 'rev-parse' '--verify' 'refs/remotes/trunk^0'\n13:26:07.923752 git.c:348 trace: built-in: git 'rev-list' '--pretty=raw' '--reverse' '74332b7d653cde7ba3b999cc7b0adcfd9d924440..refs/remotes/trunk' '--'\n13:26:07.926128 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteRoot'\n13:26:07.928707 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteUUID'\n13:26:07.933621 git.c:348 trace: built-in: git 'cat-file' '--batch'\n13:26:08.150396 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.branches-maxRev' '231655'\n13:26:08.152963 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.tags-maxRev' '231655'\n13:26:08.155457 git.c:348 trace: built-in: git 'rev-parse' '--verify' 'refs/remotes/trunk^0'\n13:26:08.158789 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.usesvmprops'\n13:26:08.160929 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.nometadata'\n13:26:08.164778 git.c:348 trace: built-in: git 'cat-file' 'commit' '74332b7d653cde7ba3b999cc7b0adcfd9d924440'\n13:26:08.169921 git.c:348 trace: built-in: git 'write-tree'\n"},{"id":"262122","messageId":"CACsJy8CqSERT+MXnU89gmSD-U9RBgRnQVyz2LAHFbCAxW-MESw@mail.gmail.com","threadId":"39369","inReplyTo":"D377A9280DB18546A2471214D5CBB0E9087568F735@exchdb01","subject":"Re: recovering from \"unordered stage entries in index\" error","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-05-26T13:37:23Z","receivedAt":"2015-05-26T13:37:23Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, May 26, 2015 at 8:28 PM, McHenry, Matt\n wrote:\n>> see these commands, or something else. Could you try again with\n>> GIT_TRACE=/absolute/path/to/some/where instead of GIT_TRACE=2 and post\n>> the content of /abso../some/where?\n>\n> It looks the same as far as I can see:\n>\n> $ GIT_TRACE=/tmp/git-trace git svn fetch\n> fatal: unordered stage entries in index\n> write-tree: command returned error: 128\n>\n> $ egrep -i 'read|tree|update|index' /tmp/git-trace\n> 13:26:08.169921 git.c:348 trace: built-in: git 'write-tree'\n\nOK I give up. Can't think of how the index is written, and by whom.\n-- \nDuy\n"}]}