Junio C Hamano <gits...@pobox.com> writes:
> I am not sure if it should be left as the responsibility of the
> caller (i.e. check the_index.initialized to bark at a caller that
> forgets to read from an index) ...
Scatch that. That would not work in a freshly created repository
before doing any "git add". An empty index is a normal state, so it
would not just be annoying to warn "You called me without reading
the index" but is simply wrong.
It was OK to have "we ensure that we've read into the_index from
some index file" as a fallback in a helper function designed to be
used in a "run once and exit" program, but I'd say as a part of
"libified" helper set, we should just make it a responsibility of
the caller to make sure whatever index entries the caller wants to
have in the_index to be used when calling this helper function.
During the course of developing whatever you are building that calls
this function, perhaps you were bitten by an unpolulated the_index,
_not_ because you genuinely could _not_ find the logical place that
is the best location to read the index file at in your code flow,
but simply because you forgot to read one and with that hindsight,
you _know_ what is the logical right place the index file should
have been read. That is what I am guessing anyway.
And I further guess that this is a well-meaning attempt to _help_
others not having to worry about _when_ exactly the index file is
But I do not think it is being helpful in the longer term. When to
read the index file and when to discard the contents matters (and
for callers to which it does not matter, they can always read it at
the very beginning of the program, because by definition it does not
matter). So let's not do this patch, unless there is some other
good reason to have it.