Junio C Hamano <gitster@xxxxxxxxx> 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 read. 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.