finding if a commit is needed

We have an interface which "rolls back" commits to a previous time in a set of data files using read-tree.

Works great ... but sometimes there are files which have been changed in the working tree which cause read-tree to fail. The files should have been committed but weren't. "git read-tree -i" isn't appropriate because we want to commit these files before the read-tree rolls them back ... because they are changes which might be resurrected and we don't want to lose them altogether.

So ...

       git commit -a -m "something" && git read-tree ...

Doesn't work when there are no files which need committing ...

       git commit -a -m "something" || git read-tree ...

Doesn't work when there are.

Is there something which can test whether a commit is needed?

I define "needed" as meaning when git commit -a would make a non-identical commit.

Many thanks, Geoff.