gitindex: inform the caller whether there were changes since the last index

[isker]

We run this fork in our indexer, which tells us whether incremental git indexing resulted in any changes. Knowing whether there were any changes can drive metrics and even help prioritize subsequent indexes (e.g. backoff indexing repos that infrequently change).

That commit as it is would certainly be an unacceptable breaking change, but I'm curious what maintainers' thoughts on this approach are. Am I missing a better way to do this? Would a not-breaking overload of IndexGitRepo that does something like this be acceptable?

[keegancsmith]

I think this API is fine to make breaking changes against. We do have an exported API, but zoekt is more meant to be consumed as a set of commands than a library. So I wouldn't want to be hamstrung based on exported API compatibility. If we wanted to be more serious about exported APIs we would need to make a lot more restructing to hide implementation details.

So that change looks fine to me. I can imagine in the future maybe returning a result type that could explain some stats on the building process for example. But lets only do the more general thing once we want it. So go for it.