RE: recovering from "unordered stage entries in index" error

This message can be improved to show what entries have this problem.

	Yes, that would definitely be a start.  :)

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

	Actually, ls-files succeeds on my broken index:

$ git ls-files > /dev/null
$ echo $?
0

	Could 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.

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?

quoted

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).

quoted

        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.)

quoted

        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:

quoted

$ 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.)

quoted

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Duy