GeezerVison

@scop are you planning to finish this up?

Ah yeah, had forgotten about it. The problem is kind of with the "improved" git ls-files parser I added here. ls-files --stage is documented to output [<tag> ]<mode> <object> <stage> <file> but I haven't been able to construct a state in which it would ever actually output anything in the tag (even if the head version is tagged), hence no possibility to add a test case to complete the coverage.

If you know how to provoke it to output the tag, pointers appreciated.

The other option would be to revert back towards the current ls-files parser which doesn't have this "problem", but then again I don't see how it could work properly in case where it was actually fed the above formatted ls-files output with a tag in it, as it picks the first space separated token from it which in those cases would be the tag, not a "tag+mode" string as the implementation/naming implies.

@asottile any thoughts about the above?

if the tag output is impossible then probably we don't need the code that would handle it

Ok, this should be good now. I was confused about the tags thing -- it's not a "git tag" in the usual sense, but just file status identifiers that will appear only if ls-files is called with -t (which we don't): http://git-scm.com/docs/git-ls-files#Documentation/git-ls-files.txt--t