On Tue, May 19, 2015 at 8:48 PM, McHenry, Matt <mmchenry@xxxxxxxxxxxxxxxxxxxx> wrote: > > > 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: > > $ git svn fetch > fatal: unordered stage entries in index This message can be improved to show what entries have this problem. But then I don't see any way to recover the index manually. ls-files will die too. Perhaps we should be gentle in this case: show warnings instead of aborting the program and internally reorder the index. I think, unless you have multiple entries with the same stage, the recovered index should run well. The broken index could be renamed to index.broken or something for later analysis, or we forbid writing the reordered index to disk. Hmm? > write-tree: command returned error: 128 > > 'git status' shows a few untracked files but is otherwise clean. > > 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). > > 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.) > > 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: > > $ git ls-files -s | cut -f 2-100 | sort | uniq -c | grep -v '^[ \t]*1 ' > > (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.) > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html