Alex Vandiver wrote:
> As part of gathering some automated performance statistics of git, it
> would be useful to be able to extract some vital properties of the
> index. While `git update-index` has ways to _set_ the index version,
> and enable/disable various extensions, AFAICT there is no method by
> which one can ask for reporting about the current state of them --
> short of re-implementing all of the index-parsing logic external to
> Git, which is not terribly appealing.
Aside: git-update-index(1) says
Version 4 is relatively young (first released in 1.8.0 in
October 2012).
My first reaction is to wonder if it is time to introduce a config
option to use index format version 4 by default, since after 5 years
it is not relatively young any more.
My second reaction is to notice that the index.version configuration
already exists. Probably git-update-index(1) ought to point to it.
JGit still doesn't support index format 4, so 4 is still not a good
default for `index.version` for a user that hasn't explicitly
configured it, but the moment JGit gains that support I think it will
be. :)
> I hesitate to propose adding a flag to `git update-index` which reads
> but does no updating, as that seems to make a misnomer of the
> command. But this also doesn't seem worthy of a new top-level command.
The existing scripting command that inspects the index is
"git ls-files".
It doesn't go into this kind of low-level detail about the index
format, though. In the same spirit, I don't think we have an existing
command in this spirit for analyzing packfiles, either.
So I agree with Junio that this would be a good debugging aid to put
in t/helper/ for now, and then once we've had experience with it we'd
end up in a better position to come up with a stable, public-facing
interface, if one is needed.
Thanks and hope that helps,
Jonathan
